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Program  Summary 


1.1  Authority:  The  Identification  Friend,  Foe,  or  Neutral  Joint  Test  and 
Evaluation  (IFFN  JTicE)  is  directed  by  the  Director,  Defense  Test  and  Evaluation, 
Office  of  the  Under  Secretary  of  Defense  for  Research  and  Engineering 
(OUSDRE/DDT&E)  through  the  Charter  of  the  Joint  Test  Director,  12  July  1979,  as 
approved  by  the  Assistant  Secretaries  for  the  Air  Force,  Army,  and  Navy  and 
implemented  by  the  Air  Force  Test  Directive  thru  HQ  United  States  Air  Force 
message  DTG  162030Z  Jul  80. 

1.2  Purpose:  ^Th  e  purpose  of  theflFFN  JT&E^is  to  assess  baseline  US  capabilities 
within  the  North  Atlantic  Treaty  Organization  (NATO)  air  defense  command  and 
control  (C^)  system  to  perform  the  IFFN  function,  identify  deficiencies  in  the 
performance  of  that  function,  and  propose  potential  near-term  procedural  and 
equipment  modifications  for  further  testing.  The  purpose  of  this  document  is  to 
serve  as  an  internal  management  tool,  provide  an  overview  of  the  objectives, 
background,  concept  of  execution,  resource  requirements,  and  acquisition  concept 
of  the  IFFN  JT8cE  and  to  provide  an  umbrella  document  identifying  the  roles  of 
all  participating  agencies^. 

1.3  Background:  It  is  widely  recognized  that  the  inability  of  operators  of  air 
defense  systems  to  discriminate  accurately  and  rapidly  between  friendly,  hostile 
and  neutral  aircraft  significantly  limits  the  effective  utilization  of  these  systems. 
This  recognition  has  stimulated  activity  within  NATO  to  develop  an  effective 
NATO  Identification  System  (NIS). 

In  1975  the  Defense  Science  Board  issued  a  report  detailing  problems 
associated  with  target  identification  for  employment  of  beyond-visual-range  (BVR) 
air  defense  weapons.  Based  on  their  report,  the  Deputy  Secretary  of  Defense 
directed  the  Joint  Chiefs  of  Staff  (JCS)  to  incorporate  the  evaluation  of  the 
identification  function  into  field  exercises  and  the  Office  of  the  Secretary  of 
Defense  (OSD)  to  integrate  the  identification  function  with  the  C?-  process  both 
organizationally  and  operationally. 

The  Institute  for  Defense  Analyses  (IDA)  was  tasked  to  further  study  these 
issues.  IDA  recommended  establishing  the  IFFN  3T&E  program.  In  July  1979,  the 
DDT&E  issued  the  Charter  for  the  Identification,  Friend,  Foe,  Neutral  Joint  Test 
and  Evaluation  Program  naming  the  Air  Force  as  the  Executive  Service  and 
included  requirements  for  Air  Force,  Army,  and  Navy  Deputy  Test  Directors  to  be 
assigned  to  the  Joint  Test  Force  (JTF)  located  at  Kirtland  Air  Force  Base,  New 
Mexico.  IDA  has  been  tasked  by  DDT&E  to  develop  the  test  concept  and  design 
which  will  be  coordinated  with  the  services  and  the  Joint  Test  Director  (JTD). 

1.4  Objectives,  Issues,  and  Impact 

1.4.1  Objectives 

During  the  test  planning  phase,  specific  objectives  along  with 
appropriate  methodology,  measures  of  effectiveness,  measures  of  performance,  and 
data  elements  will  be  developed  to  satisfy  the  issues  identified  below. 

1.4.2  Issues 

The  IFFN  JT&E  will  address  the  two  major  operational  issues  identified 
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below.  A  more  thorough  discussion  of  the  two  major  issues  to  include  their 
supporting  rationale  and  additional  specific  issues  is  contained  in  the  IFFN  Test 
Concept  Paper  and  will  be  further  amplified  in  the  Field  Test  Plan. 

1.4.2.1  Major  Operational  Issue  1.  What  is  the  contribution  of  indirect 
identification  information  to  the  ability  of  US  air  defense  command  and  control 
systems  operating  in  NATO  to  correctly  identify  airborne  targets,  use 
identification  in  performing  target  allocation,  and  aid  subordinate  air  defense 
weapons  systems  in  performing  target  acquisition? 

1J 4.2.2  Major  Operational  Issue  2.  What  are  the  weaknesses  in  the  collection, 

formation,  dissemination,  and  use  of  indirect  identification  information  for  which 
solutions  are  not  currently  planned? 

1.4.3  Impact 

a.  Satisfying  the  first  major  operational  issue  will  provide  a  baseline 
assessment  of  the  expected  identification  performance  of  a  representative  air 
defense  system  operating  in  the  Fourth  Allied  Tactical  Air  Force  (4ATAF)  area  in  a 
wartime  environment,  with  results  applicable  to  other  joint  and  combined 
environments.  It  will  also  provide  a  fuller  understanding  of  the  relationship  of 
identification  performance  of  the  command  and  control  system  to  the  performance 
of  the  overall  active  air  defense  mission.  This  understanding  should  also  provide  an 
empirical  data  base  which  can  assist  the  Services  and  OSD  in  the  formulation  of 
verification  of  operational  requirements  for  identification  and  point  to  possible 
weaknesses  in  projected  "baseline"  capability. 

b.  Satisfying  the  second  major  operational  issue  will  identify 
weaknesses  in  the  identification  process  and  allow  for  a  qualitative  comparison  of 
weaknesses  identified  during  testing,  with  existing  programmed  solutions  for  these 
weaknesses  (Service,  OSD,  and  NATO  input  of  ongoing  and  proposed  identification 
program  information  being  required  to  conduct  this  comparison).  It  should  also  be 
possible  to  postulate  potential  corrective  actions  for  those  deficiencies  that  are 
identified  that  currently  lack  a  programmed  solution.  These  recommended 
corrective  actions  could  take  the  form  of  doctrinal  or  procedural  changes,  system 
software  changes,  communications  connectivity  changes,  addition  of  new  data 
sources,  or  various  combinations  of  these  remedies.  Upon  Service  and  OSD  review 
of  these  recommendations  and  their  subsequent  input  of  additional  test  issues, 
follow-on  testing  can  be  proposed,  scheduled,  and  conducted  using  the  IFFN 
Testbed  and  acquired  data  base  for  comparisons. 

1.3  Operational  Testing  Concept 

The  concept  for  operational  testing  under  the  IFFN  JT&E  program  is  to 
replicate,  through  a  computerized  testbed,  those  operational  weapon  and  command 
and  control  system  configurations  which  will  be  in  the  field  in  the  1985-1986  time- 
frame. 

Accomplishment  of  the  test  objectives  involves  two  major  facets: 

a.  Development  of  the  Evaluation  Testbed  System  (ETS) 

b.  Conduct  of  testing 
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In  order  to  minimize  technical  and  program  risks,  a  phased  testbed 
acquisition  has  been  adopted  and  is  further  explained  in  Section  7. 

The  test  approach  is  based  on  seven  series  of  testing.  The  series  will  consist 
of  the  following  weapons  systems,  command  and  control  systems,  and  associated 
data  links: 

a.  Series  1:  System  Checkout 

PATRIOT  Fire  Unit  (FU) 

PATRIOT  Air  Defense  Information  Language  (PADIL) 


b.  Series  2:  PATRIOT  FU 


PATRIOT  Battalion  Fire  Direction  Center  (Bn  FDC) 


PADIL 


c.  Series  3:  PATRIOT  FU 

PATRIOT  Bn  FDC 


PATRIOT  Brigade  Fire  Direction  Center  (Bde  FDC) 
PADIL 

Army  Tactical  Data  Link  -  1  (ATDL  I) 


d.  Series  4:  F-15  "Eagle"  Interceptor 

e.  Series  5:  F-15 


USAF  Control  and  Reporting  Post/Message  Processing 
Center  (CRP/MPC) 

NATO  Airborne  Early  Warning  System  (NE-3A) 

Special  Information  System  (SIS) 

TADIL-A 

TADIL-B 


f.  Series  6:  PATRIOT  FU 

PATRIOT  Bn  FDC 


PATRIOT  Bde  FDC 


NE-3A 
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CRP 


SIS 

TADIL-A 
TADIL-B 
PADIL 
ATDL-1 
NATO  Link-1 
g.  Series  7:  PATRIOT  FU 

PATRIOT  Bn  FDC 

PATRIOT  Bde  FDC 

F-15 

NE-3A 

CRP 

SIS 

NATO  Control  and  Reporting  Center  (CRC) 

TADIL-A 
TADIL-B 
PADIL 
ATDL-1 
NATO  Link-1 

1.6  Testbed  Concept:  Two  major  options  were  considered  during  feasibility 
studies  when  developing  the  test  concept:  field  exercises  and  computer-based 
simulation.  Both  have  strong  and  weak  points  which  can  be  compared.  A  hybrid 
approach  was  ultimately  selected,  which  permits  us  to  capture  the  best  of  both 
options.  The  concept  is  centered  around  live  operators  using  actual  tactical 
hardware  or  accepted  simulations/simulators  of  hardware/software  identified  as 
Live  Participating  Units  (LPUs).  Real-time  computer  models  stimulate  the  LPUs 
as  well  as  represent  the  background  workload  for  these  units.  This  man-in-the-loop 
simulation  will  be  carried  out  through  the  creation  of  the  ETS.  To  implement  this 
test  concept  a  distributed  testbed  is  to  be  established.  A  central  facility  will 
generate  and  distribute  the  tactical  scenario,  control  test  execution,  and  monitor 
the  response  of  geographically  distributed  LPUs  participating  in  the  tests. 

Those  candidate  units  to  be  represented  by  tactical  equipment  or 
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simulations/simulators  of  the  tactical  equipment  and  their  proposed  location  are 
listed  below: 

U.S.  Army  PATRIOT  Fire  Unit  Ft  Bliss  TX 

U.S.  Army  PATRIOT  Battalion  Fire  Direction  Center  Ft  Bliss  TX 

U.S.  Army  PATRIOT  Brigade  Fire  Direction  Center  Ft  Bliss  TX 

U.S.  Air  Force  F-15  Interceptor  Aircraft  Multipurpose  Fighter 

Facility,  Kirtland  AFB 
NM 

U.S.  Air  Force  Control  and  Reporting  Post/  Hurlburt  Field  FL 

Message  Processing  Center 

NATO  Airborne  Early  Warning  System  Boeing  Avionics 

Integration 
Laboratory,  Seattle 
WA 

NATO  Control  and  Reporting  Center  Decision  on  the 

specific  NATO  CRC 
to  be  represented  in 
the  testbed  is  still 
pending  the  resolution 
of  several 

programmatic  issues. 

Other  systems  necessary  for  the  test  (but  represented  by  manned  simulations 
located  at  the  Central  Simulation  Facility  (CSF)  at  Kirtland  AFB)  include,  but  are 
not  limited  to,  the  Special  Information  System  (SIS),  Manual  Input  Facility  (MIF), 
and  NATO  Air  Defense  Ground  Environment  (NADGE)  System. 

At  the  request  of  the  Army,  DDT&E  in  conjunction  with  the  JTD  and  the  JTF 
staff  is  investigating  the  feasibility  of  incorporating  the  Army  HAWK  System 
within  the  IFFN  JTicE.  When  the  programmatic  issues  of  operational  requirements, 
schedule,  affordability,  and  funding  responsibilities  are  resolved,  this  document  will 
be  updated  to  incorporate  the  HAWK  System. 
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2.0  Participating  Organizations 

2.1  Joint  Test  Force 


2.1.1  JTF  Composition 

The  JTF  consists  of  the  JTD,  a  Service  deputy  from  each  of  the 
Participating  Services,  and  personnel  from  each  of  the  Services  to  plan,  conduct 
and  support  the  test.  The  JTD  has  overall  responsibility  for  the  implementation  of 
the  Test  Directive  and  is  responsible  to  the  DDT&E.  The  JTF  external 
relationships  are  shown  in  Figure  2.1. 

Each  Service  deputy  is  the  representative  for  his  Service  through  the 
Services  test  and  evaluation  agency  (Air  Force-AFOTEC,  Army-OTEA). 
Additionally  each  Deputy  Test  Director  serves  in  a  functional  position  on  the  JTF 
staff  as  manager  over  the  staff  directorates.  Figure  2.2  shows  the  current 
relationship. 

Despite  active  Navy  participation  early  in  the  IFFN  program,  the  Na*' 
elected  to  withdraw  support  for  the  program  due  to  unresolveable  programma 
issues." 


2.1.2  JTF  Responsibilities 

The  IFFN  JTF  is  responsible  for  acquiring  a  testbed  and  conducting 
test  designed  to  meet  the  program  objectives. 

Additionally,  the  JTF  is  responsible  for: 

a.  Coordinating  the  participation  of  all  Services  and  NATO  to  enable 
timely  completion  of  the  program. 

b.  Conducting  the  test  to  obtain  data  for  analysis  and  evaluation. 

c.  Evaluation  of  test  data  and  preparing  test  reports. 

d.  Ensuring  timely  reports/recommendations  are  made  to  DDT&E, 
the  Technical  Advisory  Board  (TAB),  and  the  Senior  Advisory  Council  (SAC). 

e.  Conducting  all  training. 

f.  Preparing  inputs  to  the  Five  Year  Development  Plan  (FYDP). 

g.  Reviewing  and  coordinating  test  designs. 

h.  Developing  and  coordinating  test  plans  and  procedures. 

i.  Providing  the  testing  techniques  and  the  test  results  to  the 
participating  Services  and  Defense  Agencies  to  aid  ongoing  acquisition  activities  in 
their  planning,  acquisition,  and  evaluation  of  identification  systems. 

2.1.2.1  Joint  Test  Director  (JTD) 

The  Joint  Test  Director  is  directed  under  the  Charter  to: 
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a. 


Establish  a  Headquarters  site. 


b.  Identify  and  submit  to  appropriate  Service  agencies  billet 
requirements  for  an  effective  operational  and  technical  staff. 

c.  Identify  related  Service  test  programs,  and  where  feasible, 
incorporate  into  this  test  any  pertinent  data  or  results. 

d.  Develop  detailed  test  plans. 

e.  Determine  resources  required  to  conduct  the  tests. 

f.  Undertake  necessary  actions  to  obtain  required  long-lead 
procurement  items  required  for  the  test. 

g.  Conduct  the  tests;  collect,  assemble,  and  evaluate  the  data. 

h.  Insure  timely  transmittal  of  test  data  to  DDTdcE's  analytic 
support  activity. 


i.  Provide  the  test  results  and  testing  techniques  to  the  Army,  Navy, 
and  Air  Force  to  aid  ongoing  acquisition  activities  in  their  planning,  execution,  and 
evaluation  of  identification  systems. 

j.  Submit  periodic  status  reports  to  appropriate  agencies. 

k.  Arrange  for  disposition  of  all  resources  required  to  conduct  the 

tests. 

2.1.2.2  Deputy  Test  Directors 

The  individual  Service  Deputy  Test  Directors  are  on  site  at  the  IFFN 
3TF  Headquarters,  Kirtland  Air  Force  Base.  One  of  their  primary  responsibilities 
is  to  facilitate  Service  participation  in  the  IFFN  3T&E  Program.  They  are  assigned 
to  the  IFFN  3TF  and  perform  the  following  functions: 

a.  Represent  their  respective  Service  in  3TF  matters. 

b.  Advise  the  3TD  on  Service  problems  or  changes  that  could  impact 
joint  testing. 

c.  Make  appropriate  program  and  testing  recommendations  to  the 
3TD,  and  the  respective  Service  IFFN  Program  Sponsor. 

d.  Act  as  primary  liaison  between  their  respective  Service  and  the 
3TF  for  test  activities. 

e.  Represent  their  Service  in  joint  resolution  of  test  issues. 

f.  Ensure  Service  technical  and  operational  requirements  are 
provided  to  the  IFFN  3TicE  Program. 

g.  Assist  in  the  development,  review,  coordination  and  approval  of 
joint  program  documentation. 
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STAFF  RELATIONSHIPS 


JTF 


FIGURE  2.1 


JTf  STAFF 


FIGURE  2.2 


h.  Establish  general  schedules  for  all  phases  of  their  Service 
participation,  conforming  to  those  established  by  the  JTD. 

i.  Assist  the  JTD  in  those  areas  concerning  their  respective 

Services. 

j.  Serve  as  JTF  functional  managers  as  specified  by  the  JTD. 

2.2  Service  Participation 

Each  individual  Service  is  responsible  for  the  development  and 
implementation  of  a  program  plan  to  support  the  IFFN  JT<5cE  program.  For  the  Air 
Force  this  plan  is  the  Test  Program  Outline  (TPO)  and  for  the  Army,  the  Outline 
Test  Plan  (OTP).  These  documents  list  the  personnel  and  equipment  to  be  provided 
by  the  services,  based  on  support  requirements  specified  in  this  document. 

2.2.1  General  Responsibilities 

Each  Service  also  has  general  responsibilities  including  but  not  limited 
to: 


a.  Describing,  in  general,  the  system  engineering  required  to  modify 
test  facilities/systems  to  implement  the  IFFN  Test  Design. 

b.  Facilitating  the  coordination  of  individual  Service  LPUs  and  their 
preparation  for  joint  testing. 

c.  Describing,  in  general,  the  procedure  for  certifying  the  readiness 
of  the  individual  Service  systems  and  facilities  to  participate  in  and  support  joint 
testing. 


d.  Coordinating  and  reviews  of  test  designs,  plans,  and  procedures. 

2.2.2  Air  Force  Participation.  As  the  Executive  Service,  the  Air  Force 
provides  the  IFFN  JTD  with  office  space  and  facilities  for  the  JTF  located  at 
Kirtland  AFB,  funding  for  JTF  (Kirtland)  office  equipment  and  supplies,  and 
contracting  facilities. 

As  outlined  in  the  TPO  the  Air  Force  also  provides: 

a.  Required  personnel  to  staff  the  JTF  and  those  personnel  required 
to  operate  the  Air  Force  LPUs. 

b.  Copier  equipment  rentals. 

c.  Communications  service  to  include  administrative  service  at 
participating  Air  Force  facilities,  lease  of  dedicated  computer  desk  telephone 
lines,  and  Cryptographic  equipment. 

d.  Office  equipment  and  supplies  at  Air  Force  facilities. 

2.2.3  Army  Participation.  As  outlined  in  the  OTP  the  Army  provides: 
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a.  Required  personnel  to  staff  the  3TF  and  those  personnel  required 
to  operate  the  Army  LPUs. 

b.  Communications  service  at  Ft.  Bliss. 

c.  Office  equipment  and  supplies  at  Ft.  Bliss. 

d.  Suitable  facilities  for  the  IFFN  interface  equipment  at  Ft  Bliss. 

2.3  Institute  for  Defense  Analyses  (IDA) 

As  the  principle  IFFN  evaluation  agency  for  DDT&E,  IDA  has  the 
responsibility  to  prepare  the  IFFN  Test  Design  in  coordination  with  the  JTF;  assist 
DDT&E  in  the  review  of  detailed  test  plans  developed  by  the  JTF;  monitor  the 
IFFN  tests;  and  conduct  an  independent  evaluation  of  the  test  results. 

2.4  IFFN  Contractors 

2.4.1  Evaluation  Testbed  System  Contractor.  The  ETS  contractor  will 
develop/deiiver  the  hardware  and  software  required  to  satisfy  ETS  system 
specifications.  Specifically,  the  contractor  will  be  responsible  for  all  acceptance 
test  planning,  test  documentation,  test  conduct,  analysis  of  results,  and  test 
reports  necessary  to  demonstrate  to  the  Government  satisfactory  achievement  of 
all  ETS  requirements.  It  is  envisioned  that  the  contractor  will  establish  an  internal 
quality  assurance  organization  to  coordinate  these  responsibilities  and  to  perform 
all  internal  acceptance  tests  and  inspections,  project  reviews,  configuration 
management  actions,  and  record  keeping  necessary  to  insure  completeness  of  the 
delivered  product. 

The  contractor  will  develop  the  support  programs,  documentation,  and 
technical  reports  on  the  system  and  exercise  these  programs  to  evaluate  the 
operation  of  the  testbed  and  to  evaluate/analyze  the  effect  on  system  performance 
of  any  modifications  or  changes  to  the  system. 

2.4.2  Technical  Support  Contractor.  The  Technical  Support  contractor  will 
provide  technical  and  analytical  support  to  the  JTF  in  areas  related  to  the  ETS 
implementation  (conceptual  design  through  government  operational  acceptance), 
testbed  operations,  and  technical/program  management  training. 

2.4.3  Independent  Verification  and  Validation  (IVflcV)  Contractor.  The  IV&V 
contractor  responsibility  is  to  serve  as  an  independent  team  which  provides  the  JTF 
the  capability  to  ensure  that  the  hardware,  software,  and  documentation  produced 
during  system  development  satisfies  operational  requirements  and  are  consistent 
with  specifications  and  design  documents.  The  IV&V  process  will  be  applied  to 
design  reviews,  functioned  and  physical  audits,  and  test  and  evaluation  of  the 
software/hardware  delivered  items. 

2.5  NATO  Participation 

At  the  present  time,  NATO  responsibilities  are  not  clearly  defined.  The  JTD 
will  make  a  recommendation  through  proper  channels  to  facilitate  the  interface 
with  NATO.  This  will  allow  for  necessary  liaison  including: 


a.  NATO  review  of  documentation  such  as  analysis,  design,  test 
plans,  and  procedures  and  other  publications. 

b.  NATO  recommendation  to  the  JTF. 

c.  NATO  information  necessary  to  the  conduct  of  the  IFFN 
evaluation  program. 

2.6  Interface  With  Related  Activities  and  Programs 

This  section  addresses  the  necessity  of  establishing  a  working  relationship 
with  the  Combat  Identification  System  Program  Office  (CISPO)  and  NATO 
Identification  System  Program  Office  (NI5PO)  to  ensure  that  a  coordinated  IFFN 
JTF/C1SPO/NISPO  approach  is  addressed. 

2.6.1  Combat  Identification  System  Program  Office  (CISPO) 

CISPO  is  a  joint  services  program  office  located  at  Wright-Patterson 
Air  Force  Base.  It  is  responsible  for  combat  identification  within  the  U.S.  Armed 
Forces.  CISPO  is  currently  developing  the  Combat  Identification  System  (CIS)  and 
has  prepared  the  Mission  Element  Need  Statement  (MENS)  which  has  been  approved 
by  OSD/DDR&E  C^I.  CISPO  also  supports  the  NIS  Project  Group.  A  Memorandum 
of  Agreement  (MOA)  details  the  relationship  between  the  CISPO  and  the  JTF. 

2.6.2  NATO  Identification  System  Program  Office  (NISPO) 

NISPO  is  a  NATO  organization  in  support  of  NIS  Program  Group  located 
at  NATO  HQ,  Brussels.  It  is  a  technical  advisory  group  with  a  support  function  to 
the  NIS  Program  Group.  NIS  Program  Group  is  divided  into  two  working  groups: 
Working  Group  I,  Direct  Subsystem  (DSS)  and  Working  Group  2,  Indirect  Subsystem 
(ISS).  CISPO  supports  both  Working  Groups  I  and  2. 

2.6.3  Other  Related  Programs 

The  IFFN  JTF  will  conduct  frequent  liaison  with  other  related  programs 
to  ensure  maximum  input  of  latest  information  into  test  planning  and  conduct  and 
to  ensure  efficiency  of  operation  within  DOD  with  a  view  toward  reducing 
duplicative  effort  and  utilizing  common  resources  where  applicable.  Of  particular 
interest  are  the  JINTACCS,  T ACS/TADS,  and  JFAAD  programs. 

2.6.3.1  Joint  Interoperability  of  Tactical  Command  and  Control  Systems 
(JINTACCS) 

The  JINTACCS  program  is  an  outgrowth  of  previous  joint  interface 
programs  (including  TACS/TADS).  The  program  is  concerned  solely  with  the 
exchange  of  digital  data  via  TADIL-A  (Link-1 1),  TADIL-B  and  TADIL-C  (Link  4 A) 
communication  links.  The  program  is  designed  to  improve  the  interoperability  of 
command  and  control  among  all  branches  of  the  Armed  Services. 

2.6.3.2  Tactical  Air  Control  Systems/Tactical  Air  Defense  Systems 
(TACS/TADS) 

TACS/TADS  is  a  distributed  testbed  for  testing  command  and  control 
systems  for  joint  service  use.  It  is  used  for  testing,  recertification,  reverification 


and  validation,  and  requalification  of  tactical  data  links.  The  testbed  is  still  in  use 
and  is  scheduled  for  use  within  the  JINTACCS  program  in  the  future. 

2.6.3.3  Joint  Forward  Area  Air  Defense  (JFAAD) 

JFAAD  is  an  OSD  sponsored  Joint  Test  with  the  U.S.  Army  designated 
as  executive  service.  Although  IFFN  and  JFAAD  are  focused  at  different  levels,  a 
potential  for  commonality  and  overlap  exists.  An  OSD/DDT&E  Memorandum  dated 
1  Nov  83  details  the  relationship  between  the  two  JT&Es.  Specifically,  JFAAD  will 
examine  the  scenarios  planned  for  IFFN  for  possible  use  and  IFFN  will  examine 
scenarios  and  other  output  from  JFAAD  to  determine  usefulness  in  a  timely 
fashion. 


3.0  Documentation 


3.1  General.  Since  the  IFFN  JTicE  program  is  basically  composed  of  a  testbed 
representing  several  systems,  a  central  baseline  set  of  documents  applicable  to  all 
participating  systems  and  organizations  is  being  developed  by  the  IFFN  JTF  and 
will  be  coordinated  with  the  Services/ Agencies.  The  hierarchy  of  documents 
related  to  the  program  is  shown  in  the  Documentation  Tree  in  Figure  3-1. 

3.2  Documentation  Requirements.  In  addition  to  the  Program  Master  Plan 
(PMP),  the  following  documents  are  required  to  fulfill  program  planning 
requirements: 

a.  Feasibility  Study:  This  IDA  Study  (S-492)  defined  an  IFFN  evaluation 
program  that  would  use  alternative  test  vehicles  and  provided  the  basis  for  the 
IFFN  JT&E  program. 

b.  IFFN  Charter:  This  DDT&E  document  established  the  IFFN  Joint  Test, 
designated  the  Air  Force  as  the  Executive  Service,  and  outlined  the  responsibilities 
of  the  Joint  Test  Director  and  the  Services'  Deputy  Test  Directors  in  accomplishing 
the  test. 


c.  Concept  Definition:  This  IDA  paper  (P-1460)  proposed  an  evaluation  of 
the  identification  function  in  the  context  of  a  mid-intensity,  non-nuclear  war 
typical  for  Central  Europe.  The  paper  described  the  nature  of  the  identification 
function,  program  objectives  and  structure,  programmatic  issues,  a  test  approach, 
a  review  of  general  technical  requirements,  candidate  architecture,  and  a 
strawman  testbed  concept. 

d.  Test  Directive:  This  HQ  USAF  message  stated  the  test  purpose,  test 
objectives,  evaluation  concept  and  set  US  Army,  US  Navy,  US  Air  Force,  AFOTEC, 
Tactical  Air  Command  (TAC)  and  JTF  responsibilities  in  the  conduct  of  the  IFFN 
JT&E  program. 

e.  Test  Concept  Paper:  This  document  provides  a  common  view  between 
the  JTF  and  IDA  of  the  overall  JTicE  while  identifying  to  the  "user"  community  a 
coherent,  self-consistent  JTicE.  It  also  provides  a  foundation  for  acquisition  and 
simulation  decisions  and  trade-offs  necessary  for  test  design  and  testbed 
development. 

f.  Test  Operations  Requirements  Document:  This  document  will  be 
produced  by  the  IFFN  JTF  and  defines  the  mission  and  operational  requirements, 
drives  system  acquisition  to  satify  user  needs,  and  drives  training  and  procedures  to 
satisfy  user  requirements. 

g.  Test  Design:  The  Test  Design  is  an  IDA  product  provided  for  use  by  the 
JTF  in  developing  detailed  test  plans  and  conducting  the  IFFN  tests.  The  design 
will  outline  the  overall  test  objectives,  describe  the  experimental  design,  and 
define  requirements  necessary  to  meet  the  test  objectives  and  carry  out  the 
experimental  design. 

h.  Certification  Plan:  This  plan  details  the  procedures  to  be  used  in  the 
certification  of  the  testbed.  It  outlines  the  Services'  responsibilities  in  the 
certification  effort.  It  will  be  produced  by  the  JTF. 
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i.  Field  Test  Plans:  These  documents  contain  the  test  objectives,  test 
responsibilities,  and  related  factors  applicable  to  each  participant  in  the  1FFN 
Joint  Test.  This  plan  translates  the  test  concept  and  test  design  into  "real-world" 
resources,  procedures,  and  responsibilities.  Detailed  data  anaylsis  evaluation  and 
management  plans  will  be  included.  They  will  be  produced  by  the  JTF. 

j.  Software  Management  Plan:  This  JTF  plan  establishes  design, 
performance,  and  test  methodology  for  software  programs  supporting  the  IFFN 
JT&E  program. 

k.  User's  Requirements  for  Models:  These  requirements  feed  through  the 
Model  Committee  to  Logicon  and  are  then  fed  into  their  Model  Requirements 
document  to  meet  operational  requirements.  The  Model  Committee's  function  is  to 
advise  the  JTF  on  models  and  to  determine  if  Logicon  designs  meet  operational 
needs.  The  model  development  process  is  explained  in  Appendix  H. 

l.  Configuration  Management  Plan:  This  JTF  plan  establishes  the  concepts 
and  responsibilities  for  configuration  management  of  the  IFFN  JT&E  program. 

m.  Data  Management  Plan:  This  JTF  plan  describes  the  requirements, 
responsibilities,  and  procedures  necessary  to  exercise  data  management  for  the 
IFFN  JT&E.  This  plan  addresses  the  control  of  data  from  the  establishment  of 
requirements  through  test  reporting. 

n.  Training  Plan:  There  are  two  types  of  Training  Plans.  One  plan  sets 
forth  the  methods  and  responsibilities  for  training  personnel  in  the  operation  of  the 
equipment  of  the  ETS  and  is  the  responsibility  of  the  ETS  contractor.  The  other  is 
for  training  personnel  operating  Manned  Simulating  Participating  Units  (MSPUs), 
Test  Control  Monitors  (TCMs),  etc,  in  necessary  tactics  and  will  be  produced  by  the 
JTF.  The  Training  Coordinator  insures  the  necessary  training  is  planned  for  and 
accomplished. 

o.  Acceptance  Test  Plan:  This  JTF  plan  sets  out  the  method,  schedule, 
and  benchmarks  to  be  used  in  the  formal  acceptance  of  the  ETS,  including 
hardware,  functional  (software),  and  system  acceptance  testing. 


DOCUMENTATION  TREE 


4.0  System  Engineerim 


4.1  General 


Adequate  system  engineering  is  required  for  the  implementation  of  the  IFFN 
Testbed.  It  is  concerned  with  achieving  improved  procedures  and  equipment  in  the 
air  identification  process  in  Service  ,  Joint,  and  NATO  operations. 

4.2  Developmental  Implementation 

The  purpose  of  the  IFFN  JT&E  program  is  to  assess  baseline  US  capabilities 
within  the  NATO  air  defense  command  and  control  system  to  perform  the  IFFN 
function;  identify  deficiencies  in  the  performance  of  that  function,  and  propose 
potential  near-term  procedural  and  equipment  modifications  for  further  testing. 
This  entails  facilitating  or  improving  the  flow  of  information  between  LPUs  of  the 
participating  Services  and/or  their  supporting  tactical  data  systems.  The 
information  exchange  will  take  place  across  interfaces  that  are  either  manual 
(man-to-man),  semi-automated  (man-to-computer),  or  automated  (computer-to- 
computer). 

4.3  Facilities  and  Systems 

An  analysis  is  required  to  determine  the  facilities  required  to  support  joint 
testing  and  provide  connectivity  between  the  LPUs/Systems,  the  CSF  at  Kirtland 
AFB,  and  the  communications  and  data  link  network/equipments  which  will  connect 
them.  This  analysis  is  being  conducted  by  the  JTF. 

4.4  LPU  Engineering 

An  engineering  survey  will  be  conducted  to  determine  which  current 
configurations  and  capabilities  are  applicable  to  the  IFFN  program.  The 
configuration  of  the  designated  LPUs  will  be  determined.  A  comparison  of  the 
LPUs  with  existing  platforms  and  operational  equipment  will  be  made  to  identify 
any  LPU  unique  equipment  requirements.  Maximum  utilization  of  existing 
equipment  is  planned. 

Close  coordination  with  the  Services  will  be  required  to  determine  the  extent 
of  the  interface  between  the  CSF  and  the  service  LPU.  This  is  necessary  to 
identify  interface  requirements  and  specifications  IFFN  provided  equipment  must 
meet  to  effectively  interconnect  service  LPUs  into  the  Evaluation  Testbed  System. 
A  recommendation  will  be  made  for  the  location  of  the  IFFN  JTF  provided 
equipment. 

3.0  Test  Concept  of  Operations 

5.1  Test  Execution 

5.1.1  Concept  of  Operations  for  Test  Execution.  The  conduct  of  the  IFFN 
JT&E  will  be  performed  on  the  IFFN  Evaluation  Testbed  System  which  is  defined  in 
Federal  Contract  No.  F29601-81-C-Q055,  Evaluation  Testbed  Specification  Portion, 
Feb  1981. 


There  is  no  requirement  for  live  operation  of  aircraft,  live  fire  of  weapons,  live 
operation  of  radars,  or  field  deployment  of  weapons  and  command  and  control 
systems  planned  for  representation  in  the  testbed.  The  IFFN  ETS  is  a  distributed 
testbed  consisting  of  a  Central  Simulation  Facility  at  Kirtland  AFB,  test  subjects 
(for  the  purpose  of  this  document,  test  subjects  are  synonymous  with  LPUs)  at 
locations  identified  in  Section  1  of  this  document,  and  the  associated 
communications  necessary  to  connect  the  CSF  with  the  appropriate  remote  test 
subjects. 


5.1.2  ETS  Concept  of  Operations.  The  ETS  concept  to  support  test  execution 
is  for  the  CSF  to  execute  and  distribute  a  programmed  air  scenario  to  test  subjects 
in  real  time  personnel  manning  the  LPUs  interact  with  the  scenario.  The  CSF  will 
also  record  all  data  which  can  be  collected  digitally.  Data  which  cannot  be 
collected  digitally  will  be  collected  by  IFFN  JTF  observers  at  each  remote  LPU 
location.  Voice  communications  will  be  recorded  both  at  the  CSF  and  at  remote 
LPU  locations. 

5.1.3  Test  Execution  Organization.  Test  execution  is  organized  into  seven 
series  of  testing.  Series  1  tests  the  identification  performance  of  a  representative 
US  Army  Surface-to-Air  Missile  (SAM)  System  (a  PATRIOT  Fire  Unit).  Series  2 
adds  the  PATRIOT'S  first  echelon  of  command  and  control,  the  Battalion  Fire 
Direction  Center.  Series  3  adds  the  next  level  of  command  and  control,  the 
Brigade  Fire  Direction  Center.  Series  4  tests  US  Air  Force  fighter-interceptors  (F- 
15)  alone.  Series  5  adds  associated  USAF  command  and  control  nodes  and 
information  sources.  Series  6  will  integrate  the  Army  systems  from  Series  1-3  with 
the  USAF  systems  from  Series  4  and  5  together  for  joint  operations.  Series  7  will 
add  a  CRC  to  form  the  full  up  system  to  be  tested.  For  complete  detail  and 
discussion  on  the  test  series  breakout,  refer  to  the  IFFN  Test  Concept  Paper.  See 
Appendix  B  for  the  test  series  schedule. 

The  strategy  for  a  phased  test  schedule  is  twofold.  To  accomplish  the 
first  test  concept  issue,  echelons  of  command  and  control  in  an  integrated  air 
defense  system  will  be  added  and  assessed  for  their  relative  contribution  to  the 
identification  performance  of  the  air  defense  weapons  system.  Equally  important 
is  test  schedule  integration  with  the  ETS  acquisition  schedule  and  the  availability 
of  Service-provided  test  subjects.  The  current  test  schedule  balances  acquisition 
costs  and  simulation  development  risk  against  the  need  for  early,  reportable 
results. 


The  general  location  chosen  for  the  test  subjects  is  the  battle 
management  area  of  a  representative  NATO  CRC  located  in  the  4ATAF  area.  The 
scenario  is  a  full-scale,  theater  conventional  war  involving  Warsaw  Pact  and  NATO 
forces  based  upon  a  projected  1987  threat. 

NATO  forces  will  be  projected  on  a  selected  baseline  in  the  1985-1986 
timeframe  for  capability  and  ord  ;rs  of  battle  and  updated  as  the  scenario  year 
coincides  with  the  test  year. 

The  opposing  Warsaw  Pact  forces  will  also  be  projected  based  upon  a 
1987  threat. 

5.1.4  Representation  of  Test  Subjects.  Test  subjects  will  be  represented  by 
LPUs  which  are  either  the  actual  operational  system  or  a  Service-approved, 
simulator /simulation  with  comparable  capabilities.  Critical  to  test  subject 
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representation  is  the  operator  as  an  integral  part  of  the  identification  process.  In 
ail  cases  LPUs  will  be  stimulated  from  the  CSF  and  measured  at  the  CSF  and  their 
location.  Specific  test  subjects  are  identified  in  the  IFFN  Test  Concept 
documentation. 

5.2  Test  Operations  Resource  Requirements.  The  primary  resources  required  to 
accomplish  the  IFFN  JT3cE  are  facilities,  equipment,  and  personnel.  Facility 
resources  are  those  structures  that  provide  shelter  for  service/contractor  provided 
test  equipment,  IFFN  interface  equipment,  and  office  space  for  IFFN  personnel. 
Test  equipment  resources  are  those  sets  of  hardware  needed  to  effectively  pursue 
the  IFFN  JTicE.  These  suites  of  equipment  are  designated  as  either  Service-owned 
equipment  or  IFFN  interface  equipment.  Service-owned  equipment  are  those  sets 
of  hardware,  either  actual  or  surrogate,  that  accurately  replicate  the  functions  of 
command  and  control/weapons  systems  in  an  operational  environment.  IFFN 
interface  equipment  will  be  capable  of  providing  a  realistic  air  war  environment  by 
appropriate  stimulation  of  the  test  subject  hardware.  Finally,  IFFN  JT<5cE 
personnel  requirements  include  test  subject  operators  and  IFFN  assigned  test 
control  monitors.  Test  subject  operators  are  operational  command  and 
control/ weapons  systems  personnel  who  will  be  operating  the  tactical  equipment 
during  IFFN  JT&E  testing.  IFFN  assigned  test  control  monitors  are  those 
individuals  assigned  to  the  JTF  required  to  carry  out  the  objectives  of  the  IFFN 
program. 

5.3  Personnel  Training.  The  IFFN  training  program  will  familiarize  test 
personnel  with  hardware/software  functions,  test  configuration  procedures,  and 
NATO  tactics  to  be  used  during  test  operations.  There  are  four  basic  blocks  of 
training  required  for  IFFN  test  personnel: 

(1)  System  checkout  and  systems  operations  will  cover  the 
equipment/systems  to  be  used,  its  associated  setup  procedures,  and  system 
hardware/software  operations.  This  training  for  CSF  and  Detachment  personnel 
will  be  initially  performed  by  the  primary  system  development  contractor  while 
initial  system  training  for  LPU  crews  will  be  accomplished  by  each  Service  prior  to 
release  of  these  individuals  to  support  test  operations. 

(2)  Test  configuration  procedures  will  train  test  personnel  in  those 
procedures  used  to  configure  the  system  for  test  peculiar  requirements. 

(3)  NATO  tactics  training  will  familiarize  test  personnel  in  those  NATO 
tactics  and  procedures  necessary  to  respond  to  the  IFFN  testbed  as  they  would  to 
the  actual  real  world  system.  This  training  will  be  conducted  by  IFFN  LPU 
Detachment  instructors  and  selected  IFFN  CSF  instructors. 

(4)  Continuation/upgrade  training  will  involve  increasing  and  maintaining 
CSF/LPU  operator  system  proficiency  in  using  the  system/equipment,  and  for 
presenting  any  changes  or  enhancements  to  the  system/equipment.  This  training 
will  be  conducted  by  JTF  instructors.  The  method  for  accomplishing  the  above 
training  is  through  classroom  academics  and  "hands-on"  positional  system 
operations  practice.  Classroom  presentations  will  be  lectures,  briefings,  and  seif 
study  enhanced  by  viewgraphs,  slides,  workbooks,  and  resource  documents. 
Positional  practice  will  use  the  system  consoles  at  the  CSF  and  LPUs  to  reinforce 
classroom  presentations  and  allow  for  proficiency  practice  at  all  positions  through 
simulation. 
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6.0  Resource  Requirements 

6.1  Personnel 


6.1.1  Military  Personnel.  The  personnel  requirements  for  the  conduct  of  the 
IFFN  JTicE  fall  into  several  categories.  Listed  below  are  the  total  number 
required  from  the  Services  for  the  manning  of  the  JTF.  A  breakout  of  dates  and 
specialties  required  is  located  in  Appendix  F. 

JTF  Staff 


Officers 

Enlisted 

Civilian 

TOTAL 

Air  Force 

31 

21 

15 

67 

Army 

25 

18 

l 

44 

Other 

- 

12 

- 

12 

TOTAL 

56 

51 

16 

123 

LPU  operator  and  maintenance  personnel  requirements  vary  with  each 
LPU.  A  breakout  of  personnel  required  is  located  in  Appendix  F. 

Other  military  personnel  necessary  to  the  program  include  those 
individuals  from  military  laboratories  and  other  military  activities  that  provide  ad 
hoc  assistance  to  the  JTF. 

6.1.2  Civilian  Personnel.  Civilian  personnel  requirement  fall  into  two 
categories:  civil  service  and  contractor  personnel. 

Civil  service  personnel  requirements  are  found  in  Appendix  F  as  part  of 
the  manning  requirement  for  the  JTF. 

Contractor  personnel  are  those  personnel  working  for  the  ETS 
contractor,  Independent  Verification  and  Validation  (IV<5cV)  contractor,  or  Technical 
Support  contractor  on  the  IFFN  JTdcE.  These  manning  requirements  vary  with  each 
contract  and  are  specified  in  each  contract. 

6.2  Equipment  and  Facilities.  There  is  a  requirement  for  a  number  of  special 
contracts  and  host/tenant  agreements  necessary  to  the  completion  of  the  JTicE 
program. 


6.2.1  Host/Tenant  Agreements.  Host/tenant  agreements  with  the  following 
government  activities  housing  LPUs  will  be  required: 

Ft.  Bliss,  TX  (PATRIOT  FU  and  FDCs) 

Hurlburt  Fid,  FL  (407L  CRP) 

Avionics  Integration  Laboratory,  Seattle,  WA  (NE-3A) 

As  a  minimum,  these  agreements  will  address  the  nature  and  structure 
of  the  IFFN  JTicE  program  and  the  administrative  chain  of  command.  The 
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schedule  for  testing  in  relation  to  the  use  of  system/personnel  at  the  various  sites 
and  the  following  will  be  addressed: 

a.  Responsibility  for  funding 

b.  Procedures  for  reimbursement  of  funds  (where  applicable) 

c.  Logistic  support  procedures  for  the  SSUs  located  at  the  LPU 
sites 

d.  Security  requirements 

e.  Personnel  facility  requirements  for  ETS,  test  program,  and 
associated  observers,  etc. 

f.  Office/maintenance  space  requirements. 

g.  Definition  of  points  of  contact  for  coordination  and  resolution 

of  problems 

h.  COMSEC  storage/maintenance  requirements 

6.3  Funding.  The  funding  for  the  IFFN  Evaluation  Program  will  be  provided  in 
accordance  with  Chapter  251  of  the  DoD  Budget  Guidance  Manual  7110-1-M,  and 
applicable  service  directives.  For  JT<3cE  testing,  the  individual  services  are 
reimbursed  from  the  defense  appropriation  for  joint  testing  (P.E.  65804D).  The 
funding  profile  for  the  program  is  described  in  Appendix  C.  Individual  Service 
funding  requirements/plans  will  be  contained  in  the  respective  service  program 
plans.  Basically,  these  plans  deal  with  funding  requirements  through  FY  88  and 
should  include: 

o  Program  Management 

o  JTF  Support 

o  System  Engineering/ Analysis 

o  Test  and  Evaluation 

o  Facility  Engineering 

o  Training  of  Personnel 

o  Preparation  of  unique  plans  for  the  LPUs  as  appropriate  to  include  LPU 

certification 

o  Model  Committee  participation 

They  should  also  present  a  man-year  summary  of  requirements  through  FY  88. 

In  order  to  properly  formulate  and  execute  the  budget,  the  JTD  formally 
established  the  Financial  Working  Group  (FWG)  to  review  all  facets  of  the  budget 
in  order  to  insure  the  most  effective  allocation  of  available  financial  resources. 
The  FWG  is  chaired  by  the  Director,  Resource  Management,  and  is  composed  of  the 


Director  of  Data  Automation,  Director  of  Test  Operations,  Comptroller  and  other 
members  as  determined  by  the  3TD.  The  primary  purpose  of  the  FWG  is  to 
establish  a  forum  in  which  IFFN  program  financial  requirements  are  initiated, 
evaluated  and  reviewed  on  a  continuing  basis.  This  forum  allows  for  input  from  the 
three  Directorates  on  such  matters  as  the  Evaluation  Testbed  System  and 
associated  contract  requirements,  JTF  travel  requirements,  and  supply/equipment 
requirements.  It  provides  for  the  coordination  of  initiatives  from  within  the  3TF  as 
they  relate  to  the  financial  profile  of  the  program.  Other  purposes  for  which  the 
FWG  was  established  will  be  to  evaluate  obligations  versus  budget  estimates  and 
prepare  recommended  budget  submissions/revisions  for  approval  by  the  JTD.  The 
FWG  will  meet  at  the  discretion  of  the  Chairman. 

The  Joint  Test  Force's  budgeting  process  consists  of  two  distinct  stages; 
formulation  and  execution.  Although  distinct  and  separate  because  they  involve 
different  years,  the  two  stages  run  concurrently. 

Budget  formulation  begins  each  year  with  the  April  meeting  of  the  FWG.  The 
budgets  under  consideration  are  for  the  Budget  Year  and  the  Program  Year.  The 
FWG  is  concerned  with  finalizing  requirements  for  the  Budget  Year  and 
coordinating  requirements  for  the  Program  Year.  FWG  will  meet  as  necessary 
during  the  months  of  April  and  May  in  order  to  assemble  a  recommended  budget 
submission  for  the  JTD's  approval  and  transmittal  to  OSD.  The  budget  submission 
will  be  submitted  to  OSD  during  the  first  week  in  June  for  incorporation  into  the 
OSD  budget.  Budget  formulation  continues  even  after  the  formal  submission  to 
OSD.  The  Budget  Year  and  Program  Year  budgets  are  constantly  refined  until  such 
time  as  the  Budget  Year  becomes  the  Current  Year  and  Program  Year  becomes  the 
Budget  Year. 


7.0  Testbed  Acquisition 


7.1  Overview  of  Testbed  Acquisition 

7.1.1  Acquisition  Program.  The  overall  3TF  acquisition  program  consists  of 
the  design,  development,  installation,  acceptance,  operation,  and  maintenance  of 
an  Evaluation  Testbed  System  (ET$).  To  meet  IFFN  test  objectives,  the  ETS  must 
be  capable  of: 

a.  Generating  off-line  and  representing  in  real-time  operationally 
realistic  scenarios  for  the  identification  of  airborne  targets  in  wartime 
environments. 


b.  Representing  selected  air  defense  systems  in  various  tactical 
configurations  that  interact  dynamically  within  the  real-time  scenario. 

c.  Collecting  identification-related  measurements  during  the  course 

of  testing. 

d.  Centralized  control  and  monitoring  during  all  test  operations. 

e.  Extraction,  reduction,  and  analysis  of  data  collected  during  test 

operations. 

7.1.2  Acquisition  Issues.  Many  of  the  issues  associated  with  the  acquisition 
of  the  IFFN  Testbed  are  documented  in  the  Institute  for  Defense  Analyses'  Paper 
P-1460,  "IFFN  Evaluation  Program",  dated  August  1979.  Specific  issues  addressed 
and  documented  in  that  paper  include: 

a.  The  location  of  the  3TF  and  Central  Simulation  Facility  (Kirtland 

AFB,  NM) 

b.  Testbed  Architecture 

c.  Conceptual  design  of  the  computer  system  (hardware  and 

software) 

d.  Location  of  live  participating  units 

e.  Scope  (area  of  interest,  type  of  participating  units,  number  of 

aircraft) 

f.  Realism  and  fidelity  requirements 

g.  Distributed  processing/hybrid  facility  concepts 

h.  Man-in-the-loop  requirements 

i.  Types  and  quantity  of  models 

j.  Incremental  development 

k.  Flexibility  and  modifiability  requirements 
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Scenario  requirements 


m.  Test  Issues 

n.  Risk  analysis 

o.  Contracting  strategy  for  system  design 

7.2  Testbed  Design  Concept 

7.2.1  Function.  The  function  of  the  ETS  is  to  provide  a  vehicle  to  assess 
baseline  US  capabilities  within  the  NATO  air  defense  command  and  control  system 
to  perform  the  IFFN  function,  identify  deficiencies  in  the  performance  of  that 
function,  and  propose  potential  near-term  procedural  and  equipment  modifications 
for  further  testing. 

7.2.2  Testbed  Architecture.  The  ETS  is  a  centrally-controlled  geographically 
distributed  computer  network  that  consists  of  three  functional  subsystems. 

7.2.2.1  Central  Simulation  System/Support  Data  Processing  (CSS/SDP).  This 
subsystem  consists  of  a  suite  of  seven  mini-computers,  six  array  processors,  and 
related  peripherals  physically  located  in  the  Central  Simulation  Facility  at  Kirtland 
AFB,  New  Mexico.  The  principle  means  of  interaction  is  through  dedicated 
multiported  shared  memory  and  high  speed  buses.  The  CSF  equipment  can  operate 
in  either  of  two  modes:  as  a  Central  Simulation  System  for  real  time  test 
operations  or  as  a  Support  Data  Processing  facility  for  pretest  operations,  posttest 
operations,  program  maintenance,  and  diagnostic  processing. 

7.2.2.2  Satellite  Simulation  Subsystem  (SSS).  This  subsystem  consists  of 
geographically  remote  mini-computers  and  related  peripherals  each  co-located 
with  either  an  actual  operational  air  defense  system  or  a  suitable  surrogate  (e.g. 
operational  simulator).  These  Satellite  Simulation  Units  (SSU)  interface  the  live 
operational  system  with  the  Central  Simulation  System  by  providing  the 
stimulation  required  to  operate  the  air  defense  system  in  a  simulated  environment 
without  alteration  to  the  actual  equipment. 

7.2.2.3  ETS  Communications  Subsystem  (ECS).  This  subsystem  interconnects 
the  CSS  and  the  SSS  through  leased  landlines  and  provides  the  telecommunications 
capability  to  distribute  coherent  air  truth  to  all  test  nodes,  permit  operational 
voice  and  data  link  communications,  collect  remotely  recorded  data,  and  monitor 
and  control  test  execution. 

7.2.3  ETS  Software  Subsystems.  The  major  IFFN  software  subsystems 
include  support/diagnostics,  pretest  scenario  development,  posttest  reduction  and 
analysis,  and  realtime  test. 

7.2.3. 1  Support/Diagnostics.  This  subsystem  consists  of  one  Computer  Program 
Configuration  Item  (CPCI),  the  Support,  Utilities  and  Diagnostics  CPCI,  which 
provides  CSF  and  SSU  software  utilities  to  assist  in  the  operation  of  their 
respective  computers,  CSF  and  SSU  support  software  to  aid  in  software 
development,  and  CSF  and  SSU  diagnostic  software  designed  to  diagnose  the 
operational  integrity  of  CSF  and  SSU  hardware.  The  system/support  software  will 
consist  primarily  of  off-the-shelf  software  as  supplied  by  the  various  vendors. 
Most  of  the  diagnostics  will  be  developed  by  the  prime  contractor. 


7.2.3.2  Pretest  Scenario  Development.  This  subsystem  consists  of  two  CPCIs 
which  will  allow  test  planners  to  construct  and  maintain  data  files  and  scenarios 
required  for  conducting  IFFN  ETS  tests. 

a.  The  Scenario  Planner  CPCI  will  provide  the  test  planners  with  a 
high  level  scenario  planning  language  and  accompanying  scenario  environment 
specification  tools  which  will  allow  rapid  and  reliable  scenario  design. 

b.  The  Scenario  Planner  CPCI  will  be  responsible  for  translating  the 
output  from  the  Scenario  Planner  CPCI  into  the  structure  and  format  required  by 
the  CSS  Real  Time  Test  subsystem. 

7.2.3.3  Posttest  Analysis  and  Reduction.  This  subsystem  consists  of  four  CPCIs 
which  support  the  performance  of  posttest  data  evaluation. 

a.  The  Data  Collection  CPCI  provides  the  means  for  collecting  and 
consolidating  the  data  recorded  during  real  time  and  replay. 

b.  The  Data  Reduction  CPCI  provides  the  means  for  reducing  the 
collected  data  to  a  useful  size  and  format  as  well  as  generating  the  primary  trial 
data  bases. 


c.  The  Data  Analysis  CPCI  provides  the  user  with  the  tools  to 
retrieve  data  from  the  data  bases  and  perform  analysis  of  the  trial  outcome. 

d.  The  Replay  CPCI  provides  the  user  with  the  capability  to  play 
back  a  test  exercise  using  previously  recorded  CSS  exercise  data  as  the  input. 

7.2.3.4  Real  Time  Test.  The  Real  Time  Test  Subsystem  (RTS)  consists  of  the 
CSS  real  time  CPCIs  executing  in  the  CSF  at  Kirtland  AFB  and  the  Satellite 
Simulation  Unit  real  time  CPCIs  executing  at  the  various  remote  sites.  Together 
they  comprise  the  IFFN  Tactical  Simulation  Program  (TSP).  The  CSS  CPCIs  are 
allocated  processing  on  the  basis  of  functional  relationships,  data  relationships,  and 
load  balancing  across  processors. 

a.  The  Master  Simulation  CPCI  is  responsible  for  maintaining  control 
of  test  progress,  synchronizing  simulation  time  with  all  participating  units, 
maintaining  and  distributing  track  truth  data  to  all  users. 

b.  The  Display  and  Control  CPCI  provides  the  man/machine 
interface  for  test  control,  test  monitoring,  site  status  data  monitoring,  data  link 
monitoring,  data  recording,  and  simulated  facility  control. 

c.  The  Data  Link  Simulation  CPCI  formats/transmits  and 
receives/deformats  the  data  link  message  stream  for  each  of  the  data  links  utilized 
by  the  CSS  RTS. 


d.  The  Participation  Unit  Simulation  CPCI  simulates  the  detection, 
tracking,  threat  evaluation  and  scheduling,  and  facility  control  functions  of  each 
simulated  facility  unit.  This  CPCI  discretely  models  each  simulated  unit  data  link 
processing  as  required  for  IFFN  testing. 

7.2.4  Documentation.  Documentation  for  the  Evaluation  Testbed  System  is 
based  on  the  identification  of  formal  configuration  items  (CIs)  and  the 
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configuration  baseline  approach  implemented  for  Configuration  Management  (CM). 

7.2.4. 1  Configuration  Items  (Cl).  Three  configuration  items  make  up  the  IFFN 
Evaluation  Testbed  System:  the  master  Cl,  system/equipment  CIs  and  computer 
program  CIs. 


a.  Master  Cl.  The  IFFN  ETS  is  considered  to  be  the  master  system 
configuration  item.  It  is  comprised  of  all  equipment  and  computer  programs 
necessary  to  perform  the  system  functions  in  accordance  with  the  prime  contract 
Statement  of  Work  (SOW).  The  ETS  does  not  include  the  Live  Participating  Units 
but  interfaces  and  interacts  with  them  to  accomplish  IFFN  Joint  Test  Program 
objectives. 


b.  System/Equipment  CIs.  The  system/equipment  CIs  correspond  to 
the  equipment  and  computer  programs  associated  with  each  of  the  three 
subsystems  described  in  paragraph  7.2.2  above  i.e.  the  CSS/SDP,  the  SSS,  and  the 
ECS. 

c.  Computer  Program  CIs  (CPCIs).  The  Computer  Program  CIs 
correspond  to  the  CPCIs  that  comprise  each  of  the  five  functional  software 
subsystems  described  in  paragraph  7.2.3  above. 

7.2.4.2  Baselines.  The  establishment  of  baselines  provides  for  an  orderly, 
controlled  transition  from  one  step  of  development  to  the  next.  Baselines  are 
defined  by  formally  designated  sets  of  approved  technical  documentation  that 
specify  testbed  design  and  performance  requirements  and  serve  as  points  of 
departure  for  subsequent  hardware/software  development.  The  establishment  of 
each  baseline  is  preceded  by  the  development  of  specific  documentation,  a  formal 
review/audit  of  this  documentatin,  and  the  systematic  alteration  (change  control) 
of  any  previously  approved  documents  or  any  portion  of  the  documents  currently 
under  review. 


7.2.4.3  Baseline  Descriptions.  Three  baselines  are  identified:  Functional, 
Allocated,  and  Product.  These  baselines  refer  to  selected,  approved  documentation 
describing  configuration  identification  at  various  points  in  the  program  in 
accordance  with  standard  military  configuration  management  methodology  and  the 
IFFN  JTF  testbed  configuration  management  concepts. 

7.2.4.3.1  Functional  Baseline  (FBL).  The  Functional  Baseline  is  a  set  of  basic 
design  documentation  which  receives  JTF  approval  as  a  result  of  formal 
Preliminary  Design  Review  (PDR).  Included  are  the  following  documents: 


a.  Initial  System  Specification  (Type  A) 

b.  Prime  Item  Development  Specifications  (Type  Bl) 

c.  Computer  System  Specifications 

d.  User  Language  Specification 

e.  Data  Requirements  Document 

7.2.4.3.2  Allocated  Baseline  (ABL).  The  Allocated  Baseline  is  a  set  of 

design  documentation  which  receives  JTF  approval  as  a  result  of  formal  Critical 
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Design  Review  (CDR)  and  a  Design  Configuration  Audit  (DCA).  In  addition  to  the 
Functional  Baseline,  the  documents  included  in  the  Allocated  Baseline  are: 


a. 

Interface  Design  Specifications 

b. 

Interface  Control  Document 

c. 

Program  Performance  Specifications 

d. 

Program  Design  Specifications 

e. 

Common  Data  Base  Design  Document 

f. 

Disk  Data  Base  Design  Document 

g- 

C  level  Specifications  (for  developmental  hardware  items) 

7.2.4.3.3  Product  Baseline  (PBL).  The  Product  Baseline  is  a  set  of 

documentation  which  receives  JTF  approval  as  a  result  of  Functional  Testing, 
Integration  Testing,  the  Functional  Configuration  Audit  (FCA),  Operational 
Acceptance  Testing  and  the  Product  Configuration  Audit  (PCA).  In  addition, 
documents  included  in  the  Product  Baseline  are: 

a. 

System  Operator's  Manual 

b. 

Engineering  Drawings 

c. 

C  level  Specifications 

d. 

Program  Description  Documents 

e. 

Program  Package  Documents 

7.3  Testbed  Aquisition  Strategy 

7.3.1  Acquisition  Strategy.  The  JTF  acquisition  strategy  is  based  on  a  three 
phased,  cost  plus  award  fee  contract  for  the  design,  development,  installation,  test, 
and  support  of  the  hardware  and  software  that  will  comprise  the  IFFN  Evaluation 
Testbed  System.  The  contract  strategy  includes  an  award  for  Phase  I,  exercise  of 
an  option  for  Phase  II,  and  the  addition  of  Phase  III  pursuant  to  a  supplemental 
agreement  at  some  future  date  of  the  contract  effort. 

a.  In  Phase  I  (Design)  the  contractor  will  generate  MIL-STD-490  type 
B1  and  Cla  specifications  based  on  the  contract  Statement  of  Work  (SOW)  and  the 
government  furnished  IFFN  Evaluation  Testbed  System  Specifications.  The 
contractor  will  undergo  a  Preliminary  System  Design  Evaluation  (PSDE)  and  a  Final 
System  Design  Evaluation  (FSDE).  The  end  result  of  Phase  I  will  be  an  established 
functional  baseline  design  of  the  IFFN  Evaluation  Testbed  System.  The  objective 
of  Phase  I  is  to  have  the  inherent  risks  (technical,  cost,  and  schedule)  and  the 
possible  trade-offs  analyzed  and  refined  prior  to  selection  of  a  testbed  design 
concept  to  achieve  the  overall  program  technical  objectives. 

b.  Upon  favorable  IFFN  JTF  evaluation  of  the  contractor's  design  at 
FSDE,  the  option  for  Phase  II  will  be  exercised.  Phase  II  will  consist  of  the 
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detailed  design,  development,  installation,  integration,  and  test  of  the  initial 
testbed  system.  Phase  II  will  be  divided  into  three  overlapping  stages  (1-3)  each  of 
which  incrementally  implements  additional  system  capabilities  to  permit  execution 
of  the  progressive  testing  concept  described  in  paragraph  5.1.3,  Test  Execution 
Organization.  During  each  stage,  the  contractor  will  update  the  Type  B1  and  Cla 
specifications  developed  during  Phase  I  as  well  as  generate  Type  B5  and  C5 
specifications.  The  updated  and  new  specifications  will  be  reviewed  at  a 
Preliminary  Design  Review  (PDR)  and  approved  at  a  Critical  Design  Review  (CDR) 
for  each  stage.  This  activity  will  insure  that  the  contractor  integrates  the  various 
functional  subsystems  to  meet  the  testbed's  technical  objectives  and  documents 
and  changes/upgrades/modifications  to  maintain  configuration  control.  As  such,  an 
allocated  baseline  can  be  established  and  maintained  as  each  stage  undergoes 
development.  At  each  stage,  several  fundamental  events  take  place  including: 

(1)  Hardware  acquisition  and  installation 

(2)  Software  development  which  includes 

(a)  Scenario  development  and  stimulation 

(b)  Simulation  of  new  air  defense  test  elements 

(c)  Data  extraction/reduction/correlation 

(3)  Software  enhancement  to  upgrade  previously  developed 

simulations  and  testbed  capabilities. 

(4)  Integration  and  checkout  of  Live  Participating  Unit(s) 

associated  with  the  stage. 

The  end  result  of  Phase  II  will  be  an  operational  testbed  system  capable  of 
supporting  the  first  four  test  series  depicted  in  Appendix  B.  Appendix  D  shows  the 
schedule  and  composition  for  each  stage  of  Phase  II. 

c.  Phase  III,  if  added,  will  consist  of  two  stages  (4-5)  and  will  entail 
upgrading  the  Phase  II  Testbed  to  incorporate  additional  LPU  capabilities.  The 
same  activities  accomplished  during  the  Phase  II  stages  will  be  required  for  each 
stage  in  Phase  III.  The  end  result  of  Phase  III  will  be  a  Testbed  system  capable  of 
replicating  all  the  essential  elements  of  the  NATO  air  defense  command  and 
control  system  described  in  paragraph  5.0,  Test  Concept  of  Operations.  See 
Appendix  D  for  the  schedule  and  composition  for  each  stage  of  Phase  III. 

7.3.2  Contract  Type.  A  Cost  Plus  Award  Fee  (CPAF)  completion  contract  is 
contemplated  for  all  phases.  A  cost  reimbursement  arrangement  is  necessary 
based  on  the  high  technical,  cost,  and  schedule  risks  involved  with  the  successful 
completion  of  the  program  requirement.  In  addition,  the  stated  risks  could  negate 
the  effect  of  established  performance,  schedule,  and  cost  incentives.  For  this 
reason,  an  award  fee  arrangement  is  suited  to  the  proposed  acquisition  and  will 
provide  greater  incentive  than  any  other  fee  arrangement.  Award  fee  criteria  will 
be  established  and  monitored  by  technical  and  contracts  personnel. 

7.3.3  Independent  Verification  and  Validation  Contract.  As  part  of  the  JTF's 
acquisition  strategy,  an  IV&V  contractor  will  be  obtained  to  provide  the  JTF  with 
an  organization  independent  of  the  prime  ETS  contractor.  Their  primary 
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responsibility  will  be  to  ensure  that  the  ETS  meets  the  government's  specifications 
and  operational  requirements.  The  contract  effort  will  consist  of  a  contractor 
performing  IV&V  activities  during  the  acquisition  design,  development,  and 
installation,  and  test  phases  of  the  IFFN  Testbed.  The  process  will  consist  of 
design  reviews,  functional/physical  audits,  and  test  and  evaluation  of  the 
software/hardware  delivered  items. 

7.3.4  Technical  Support  Contract.  The  complexity  of  the  ETS  system 
requires  a  continuous  effort  to  ensure  that  all  system  requirements  are  identified, 
developed,  and  successfully  integrated  into  the  program.  A  separate  Technical 
Support  contract  will  be  issued  to  support  the  JTF  staff  in  this  effort.  The 
objective  of  the  Technical  Support  contract  is  to  provide  technical  and  analytical 
efforts  in  support  of  the  design,  implementation,  and  operation  of  the  ETS.  Some 
of  these  subtasks  are  Test  Plan  Development,  Scenario  Development,  Testbed 
Implementation  Support,  Testbed  Operations  Support,  ETS  Management  and 
Control,  and  Training. 

7.4  Testbed  Acquisition  Management. 

7.4.1  Objectives.  The  primary  objectives  of  the  3TF  acquisition  management 
approach  are  to: 


a.  Ensure  that  a  test  vehicle  capable  of  satisfying  IFFN  program 
objectives  is  developed. 

b.  Assure  product  quality  is  built  into  the  ETS. 

c.  Reduce  risks  (technical,  cost,  schedule)  to  an  acceptable  level. 

d.  Control  changes  that  may  impact  the  acquisition. 

e.  Insure  satisfactory  contractor  performance  is  obtained. 

7.4.2  Acquisition  Responsibility. 

7.4.2. 1  Program  Manager  (PM).  Overall  management  and  conduct  of  the  IFFN 
acquisition  program  is  the  responsibility  of  a  Program  Manager  (PM)  appointed  by 
the  JTD.  The  PM  is  principally  responsible  for  managing  all  aspects  of  the  IFFN 
ETS  contract  including  program,  technical,  and  administrative  management.  The 
PM  interfaces  with  the  prime  contractor's  program  manager  on  all  management 
issues  (e.g.  contract  scope,  schedule,  cost,  resources,  etc.)  that  may  affect  the 
acquisition.  The  JTD,  however,  is  the  sole  individual  authorized  to  give  program 
direction  and  approve  contract  changes.  The  PM  is  the  focal  point  for  all  activities 
relating  to  the  ETS  acquisition.  He  coordinates  with  the  appropriate  Service 
Deputies  on  action  items  requiring  specific  service  support  and  interfaces  with 
IV&V  and  Tech  Support  contractor  program  managers  as  required.  The  PM's  staff 
consists  of  JTF  functional  specialists  needed  for  program  execution  and  forms  an 
essentially  self-contained  organization.  These  positions  will  be  described  in  the 
following  paragraphs. 

7.4.2.2  Deputy  Program  Manager  (DPM).  The  Deputy  Program  Manager  is 
responsible  for  supervising  and  coordinating  the  activities  of  the  PM's  staff.  He  is 
responsible  for  the  day-to-day  coordination  of  all  contract  activities.  He  assists 
the  PM  in  planning,  executing,  and  monitoring  all  aspects  of  the  ETS  contract  in 
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particular  and  the  acquisition  program  in  general.  He  acts  for  the  PM  in  his 
absence.  In  addition,  the  DPM  functions  as  the  ETS  System  Engineer  and  is 
responsible  for  insuring  the  technical  and  engineering  integrity  of  the  ETS  including 
compatibility  of  actual  tactical  hardware  or  operational  simulators  interfaced  into 
the  ETS.  As  System  Engineer,  the  DPM  directly  supervises  JTF  Technical 
Representatives  to  the  Contracting  Officers  (TRCOs). 

7.4.2.3  Technical  Representative  to  the  Contracting  Officer  (TRCO).  A 
TRCO  is  the  PM's  principal  liaison  officer  with  a  specific  contractor's  program 
manager  on  all  technical  issues  and  is  the  only  authorized  JTF  personnel  to  issue, 
with  PM  and/or  JTD  approval,  technical  direction  to  the  contractor.  The  TRCO 
will  monitor  and  control  all  contact  that  may  be  necessary  between  JTF  functional 
area  technical  experts  and  the  contractor.  TRCOs  directly  responsible  to  the  JTF 
PM  are  the  ETS  and  IV«ScV  contract  TRCOs  and  TRCOs  to  be  appointed  for  each 
system  specific  LPU  acquisition.  The  TRCOs  responsibilities  include:  coordinating 
contractor/JTF  activities  on  technical  issues;  conducting  technical  interchanges 
with  the  contractor;  process/ track/control  technical  action  items  resulting  from 
interchanges,  meetings,  formal/informal  reviews  and  change  requests; 
coordinate/interface  with  other  TRCOs  and  contract  management  personnel; 
monitor  contractor  performance;  and  maintain  an  accurate  acquisition  schedule  of 
events  for  input  into  the  overall  JTF  program  schedule. 

7.4.2.4  Contracting  Officer  Representative  (COR).  The  COR  is  the  individual 
assigned  as  the  IFFN  business  manager  for  JTF  contracts  and  is  directly  responsible 
to  the  Director,  Resource  Management.  However,  he  is  one  of  the  principal  liaison 
officers  with  contract  program  managers  and  advises  the  JTF's  PM  on  all  pertinent 
contract  matters.  The  duties  of  the  COR  include  interfacing  with  the  Kirtland 
Contracting  Office,  verifying  compliance  with  contractual  requirements,  assisting 
TRCOs  in  determining  technical,  schedule,  and  cost  impacts  of  any  changes  to  the 
scope,  level  of  effort,  total  cost  and  period  of  performance  of  the  contract,  and 
monitoring  the  financial  status  of  the  contract. 

7.4.2.5  JTF  In-Plant  Representative  (Detachment  8).  The  in-plant 
representative  serves  as  the  ETS  TRCO's  assistant  and  on-site  coordinator  with  the 
prime  ETS  contractor.  He  monitors  contractor  progress/attitudes,  participates  in 
contractor  development  efforts  on  a  non-interference  basis,  facilitates  JTF 
directions/redirections  from  the  ETS  TRCO,  and  reports  on  contractor  problems 
and  progress.  The  in-plant  representative  maintains  close  coordination  with  the 
ETS  TRCO  and  the  COR  to  insure  complete  understanding  of  JTD  and  PM  policies 
and  guidance. 

7.4.2.6  Acquisition  Management  Division.  The  Acquisition  Management 
Division  is  directly  responsible  to  the  PM  for  the  administrative  management  of 
each  acquisition  stage's  life  cycle  and  for  implementing  JTF  Quality  Assurance 
and  Configuration  Management  procedures  in  support  of  the  overall  ETS  acquisition 
effort. 

7. 4.2.6. 1  Stage  Managers.  Stage  Managers  are  directly  responsible  for  all 
administrative  matters  pertaining  to  the  acquisition  stage  to  which  assigned.  They 
are  responsible  for  planning,  coordinating,  scheduling,  monitoring,  and  reporting  on 
all  acquisition  milestones  associated  with  a  stage,  such  as  formal  reviews,  tests, 
audits,  and  deliveries.  The  Stage  Manager  coordinates  closely  with  the  ETS  TRCO, 
the  COR,  other  Stage  Managers,  other  TRCOs  (e.g.  IV&V),  and  JTF  functional  area 
experts  to  insure  all  stage  contractual  requirements  are  satisfied. 
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7.4.2.6.2  Quality  Assurance  (QA).  JTF  Quality  Assurance  personnel  are 
responsible  for  insuring  that  JTF  QA  procedures  are  properly  administered  and 
implemented  both  within  the  JTF  and  by  the  ETS  contractor.  They  work  in  close 
coordination  with  the  IV&V  TRCO  during  design  reviews,  audits,  and  test  and 
evaluation  of  software/hardware  delivered  items  to  ensure  that  the  ETS  meets  the 
government's  specifications  and  operational  requirements. 

7.4.2.6.3  Configuration  Management  (CM).  JTF  Configuration  Management 
personnel  are  responsible  for  insuring  that  JTF  CM  plans  and  procedures  are 
properly  administered  and  implemented  both  within  the  JTF  and  by  the  ETS 
contractor.  Of  primary  importance  is  to  insure  that  the  integrity  of  baseline  ETS 
configuration  identification  is  maintained  and  that  changes  to  the  baseline  are 
strictly  controlled  and  processed  in  accordance  with  established  CM  procedures. 

7.4.2.7  Functional  Area  Experts.  Functional  Area  Experts  are  JTF  personnel 
who  are  specialists  responsible  for  reviewing,  monitoring,  and  evaluating  the  design 
and  development  of  an  assigned  functional  area  of  the  ETS.  They  are  augmented 
when  possible  by  JTF  personnel  in  other  directorates  and  selected  experts  from 
Service  and  civilian  agencies  to  insure  that  JTF  requirements  and  specifications 
are  contained  in  the  ETS  contractor's  products.  The  Functional  Area  Experts 
facilitate  responsive  and  open  communications  between  the  JTF  and  the  ETS 
contractor  and  closely  coordinate  their  activities  with  the  ETS  TRCO  and  Stage 
Managers.  They  also  insure  that  areas  that  affect  offices  of  collateral 
responsibility  are  coordinated  with  and  kept  informed. 
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S.O  Testbed  Certification 


8.1  General.  As  defined  in  this  testbed,  certification  is  a  function  designed  to 
assure  the  fidelity  of  the  testbed.  This  function  will  ensure  that  the  testbed,  or  a 
portion  thereof,  is  an  adequate  representation  of  the  real-world  system  that  is 
being  simulated. 

8.2  Approach.  The  general  approach  chosen  to  certify  the  testbed  is  to  compare 
testbed  operations  with  live  operations  under  identical  conditions  (scenarios).  Live 
operations  data  will  be  collected  from  exercises  conducted  for  system  evaluations 
and/or  training  purposes.  The  testbed  would  be  set  up  to  simulate  the  situations 
observed  in  the  exercise,  i.e.,  same  background,  environment,  systems 
configuration,  and  rules  of  engagement. 

Comparisons  of  the  field  exercises  and  corresponding  testbed  operation  will 
be  performed  at  three  levels. 

a.  Opinions  of  experienced  air  defense  operators  as  to  the  realism  of  the 
testbed  and  the  results. 

b.  Comparison  of  the  identification  and  engagement  statistics,  as  defined 
by  the  test  measures  of  effectiveness. 

c.  Comparison  of  time  of  occurence  of  major  track  events;  i.e.,  detection, 
identification,  and  engagement. 

The  prime  contractor  will  develop  an  Operational  Acceptance  Test  (OAT) 
Plan  for  each  stage  which  will  incorporate  JTF-developed  scenarios  that  will 
satisfy  portions  of  the  certification  requirements. 

The  JTF  will  conduct  an  Initial  Operational  Test  and  Evaluation  (IOT4cE). 
This  effort  will  support  certification  in  those  areas  not  covered  during  OAT. 

It  is  hoped  that  through  this  process  the  Services,  as  the  ultimate  users  of  the 
testbed  data,  will  receive  the  best  assurance  that  they  are  getting  a  substantive 
product. 

Further  discussion  of  the  certification  process  can  be  found  in  the 
Certification  Design  to  be  produced  by  IDA  and  the  Certification  Plan  to  be 
produced  by  the  JTF. 


WILLIAM  R.  DAVIS,  COL,  USAF 
Joint  Test  Director 
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APPENDIX  A 


REFERENCES 


Though  each  listed  reference  may  not  be  mentioned  specifically  in  the  text  of  this 

document,  each  does  contribute  to  some  facet  of  the  Program  Master  Plan  and  will 

provide  excellent  information  for  IFFN  Program  personnel. 

a.  DoD  Directive  5000.1  Major  System  Acquisitions 

b.  DoD  Directive  5000.2  Major  System  Acquisition  Process 

c.  DoD  Directive  5000.3  Test  and  Evaluation 

d.  DoD  Joint  Test  and  Evaluation  Procedures  Manual 

e.  OUSD  Memorandum;  Subject:  Joint  Test  -  Identification  Friend,  Foe,  or 
Neutral  (IFFN)  dated  23  March  1979. 

f.  OUSDRE/DDTE  Memorandum;  Subject:  Joint  Test  -  Identification  Friend, 
Foe,  or  Neutral  (IFFN)  dated  26  June  1978. 

g.  OUSDRE  (T<ScE)  Memorandum;  Subject:  Joint  Operational  Test  Funding 
Policy,  dated  1 1  February  1974. 

h.  OUSDRE  Memorandum;  Subject:  IFF  Development  Program  dated  19  January 
1979. 

i.  DoD  Memorandum  of  Agreement  on  Multiservice  OT&E  and  Joint  T<5cE  dated 
27  March  1979. 

j.  DDT&E  Charter  for  Test  Director  of  Joint  Test  Identification  Friend,  Foe,  or 
Neutral  (IFFN)  dated  12  July  1979. 

k.  HQ  USAF  Message,  P162030,  July  1980;  Subject:  Test  Directive  for  the 
Identification  Friend,  Foe,  or  Neutral  (IFFN)  Joint  Test  and  Evaluation 
(JT&E). 
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APPENDIX  F 


SERVICE  RESOURCE  REQUIREMENTS 


This  appendix  contains  the  information  on  personnel,  equipment  and  facilities 
requirements  from  the  Services  in  order  for  the  JTF  to  conduct  the  IFFN  3T&E.  It 
is  separated  by  Service  and  provides  the  information  in  sufficient  detail  for  the 
Services  to  generate  their  respective  support  plans  (Air  Force  -  TPO,  Army  -  OTP). 
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A.  Air  Force  Personnel  Requirements 


Position 


Grad< 


Test  Director  C 

AF  Deputy  Test  Director  G 

Dir,  Resource  Management  0 

Dir,  Test  Operations  Q 

Ops  Rqmts  Off  G 

Dir,  Data  Automation  G 

USAFE  Liaison  Officer  0 

Ch,  Business  Mgmt  Div  0 

Dep  Ch,  Detachment  1  Note  1  Q 

Ch,  Air  Force  Test  Ops  Div  0 

Ch,  Detachment  3  0 

Fighter  Ops  Off  0 

Ch,  Detachment  6  Npte  6  q 

Ch,  Support  and  Evaluation  Div  0 

System  Engr  0 

Ch,  Test  Support  Div  0 

Ch,  Communications  and  Tng  Div  0 

Ch,  Training  Branch  0 

Ch,  Contracts  Branch  0 

Contracting  Off  Rep  0 

Chief,  Cmd  &  Control  Br  0 


Position 

Grade 

AFSC 

Rqrd  Dates  (FY) 

Ch,  Detachment  8  Note  & 

0-4 

5135B 

82-88 

Weapons  Controller  Note  5 

0-3 

G1744D 

85-88 

E3A  Ops  Off 

0-3 

G1744G 

84-88 

Ops  Off 

0-3 

1744F 

82-88 

Scientific  Analyst 

0-3 

2685 

81-88 

Ch,  Computer  Ops  Branch 

0-3 

5155 

80-88 

ETS  TRCO 

0-3 

5135D 

81-88 

IV&V  TRCO 

0-3 

5135C 

81-88 

Cost  and  Mgmt  Analyst 

0-3 

6924 

83-88 

Elec  Warfare  Officer 

0-3 

227  5P 

83-88 

Financial  Mgmt  Supt 

E-8 

67299 

80-88 

Chief,  Central  Admin  Div 

E-8 

70299 

80-88 

NCOIC,  Computer  Ops  Br 

E-7 

51170 

80-88 

Cost  and  Mgmt  Analyst 

E-7 

69170 

82-88 

Communications  Supt 

E-7 

30770 

80-88 

NCOIC,  Air  Force  Test  Ops  Div 

E-7 

27470 

81-88 

Acceptance  Test  Mgr 

E-7 

51171 

81-88 

Chief,  Supply  Unit 

E-6 

64570 

80-88 

NCOIC,  Trng  Br 

E-6 

27470 

81-88 

NCOIC,  Software  Mgmt  Br 

E-6 

5 1 17  L 

81-88 

Pseudo  Pilot 

E-6 

27670 

85-88 

Simulator  Operator 

E-6 

27670 

84-88 

NCOIC,  Tech  Document  Br 

E-5 

70250B 

80-88 

QA  Monitor 

E-5 

51151 

81-88 

Admin  NCO 

E-5 

70250B 

81-88 

Position 

Grade 

AFSC 

Rqrd  Dates  (FY) 

Staff  Cmd  Post  NCO 

E-5 

27450 

82-88 

Simulator  Operator 

E-5 

27650 

84-88 

Simulator  Operator 

E-5 

27650 

84-88 

Simulator  Operator 

E-5 

27650 

84-88 

Acceptance  Test  Mon 

E-5 

51151 

82-88 

Computer  Operator 

E-5 

51150 

83-88 

Senior  Scientist 

GS-14 

84-88 

Ch,  Assurance  Mgmt  Br 

GS-12 

6524 

81-88 

Senior  Ops  Analyst 

GS-12 

2685 

84-88 

Secretary/Steno 

GS-6 

70270 

80-88 

Secretary/Steno 

GS-5 

70270 

80-88 

Secretary/Steno 

GS-5 

70270 

80-88 

Secretary/Steno 

GS-5 

70270 

80-88 

Secretary/Steno 

GS-5 

70270 

80-88 

Secretary/Steno 

GS-5 

70270 

82-88 

Secretary/Steno  Note  5 

GS-4 

70270 

82-88 

Secretary/Steno  Note  3 

GS-4 

70270B 

85-88 

CM  Clerk  Typist 

GS-4 

70270 

82-88 

Clerk/Typist 

GS-4 

70250B 

81-88 

Secretary /Typist 

GS-4 

70270 

81-88 

Secretary /Typist 

GS-4 

70270 

83-88 

Note  I  Ft  Bliss,  TX 

Note  3  Hurlburt  Fid,  FL 

Note  5  Avionics  Integration  Lab,  Seattle,  WA 


Note  6  Fullerton,  CA 
Note  8  San  Diego,  CA 

B.  Air  Force  Equipment  and  Facilities  Requirements 


1. 


2. 


3. 


Air  Force  Rentals 

Item  Qty 

Location 

Read  Date  (FY) 

Copier 

2 

Kirtland  AFB  NM 

83-88 

Copier 

1 

Seattle  WA 

85-88 

Copier 

1 

Hurlburt  Fid  FL 

86-88 

Copier 

1 

Ft  Bliss  TX 

83-88 

Communications  Equipment 


Item 

Qty 

Reqd  Dates  (FY) 

Dedicated  Computer  Data  Telephone  Line 

16 

83-88 

KG  13/84 

36 

83-88 

Range  and  Test  Facility  Support 

Item 

Qty 

Location 

Reqd  Dates  (FY) 

Central  Simulation  Facility 

1 

KAFB 

81-88 

(CSF)  (13500  sq  ft) 

Housing  for  IFFN  Personnel 

107 

KAFB 

81-88 

on/off  Base 

407 L  CRP/MPC 

1 

Hurlburt  FLd 

86-88 

Office  Space  (4  personnel) 

I 

Hurlburt  Fid 

86-88 

Truck,  ft  ton  or  less 

1 

KAFB 

80-88 

F-5 


4.  Service  Contracts 


GEADGE  CRC 

Contract  for  CSF  Software  and  Hardware 
E3A  Mission  Simulator 


Supplies 


Office  Supplies  94  Personnel 

Office  Supplies  3  Personnel 

Office  Supplies  4  Personnel 


Location 


Fullerton  CA 


KAFB 


Reqd  Dates  (FY) 
85-88 


80-88 


AIL,  Seattle  WA  85-88 


Location 


KAFB 


Seattle  WA 
Hurlburt  Fid 


Reqd  Dates  (FY) 


83-88 


85- 88 

86- 88 


6.  Other  Equipment 

Other  equipment  necessary  includes  office  furniture,  typewriters,  projectors, 
microfiche  viewers,  calculators,  telecopiers,  safes,  word  processors,  etc.  These  are  too 
numerous  to  list  in  this  document  and  can  be  determined  by  contacting  the  JTF. 


IL  Army 


A.  Army  Personnel  Requirements 


Position 

Grade 

MOS 

Rqrd  Dates 

USA  Deputy  Test  Director 

0-6 

51B14 

79-88 

Chief,  Detarhment  1  Note  1 

0-5 

14D51 

82-88 

Dep  Dir,  Data  Automation 

0-4 

53A14 

81-88 

Dep  Dir,  Resource  Management 

0-4 

42A54 

81-88 

Dep  Dir,  Test  Operations 

0-4 

14D54 

80-88 

Ch,  Army  Test  Ops  Div 

0-4 

51B14 

80-88 

Comptroller 

0-3 

97B45 

80-88 

Chief,  Comm  Br 

0-3 

25C53 

80-88 

Chief,  Rqmts  and  Sim  Br 

0-3 

49A14 

80-88 

Chief,  Test  Plans  and  Proc  Br 

0-3 

14D54 

81-88 

Officer,  Detachment  1  Note  1 

0-3 

14G54 

81-88 

PATRIOT  Officer,  Detachment  1  Note  1 

.  0-3 

14E54 

82-88 

Chief,  Scenario  Br 

0-3 

35B51 

83-88 

Dep  Ch,  Detachment  3  Note  3 

0-3 

14G51 

85-88 

C^  Officer,  Detachment  6  Note  6 

0-3 

14G51 

85-88 

PATRIOT  Off,  Detachment  6  Note  6 

0-3 

14E51 

85-88 

C2  Offirer,  Detarhment  7  Note  .7 

0-3 

14G51 

85-88 

Ch,  Analysis  Br 

0-3 

49A14 

81-88 

Ops  Analyst,  Analysis  Br 

0-3 

49A14 

81-88 

Chief,  Software  Mgmt  Br 

0-3 

53A14 

81-88 

Chief,  CTS  Development  Div 

0-3 

53A14 

81-88 

F-7 


Position 

Grade 

MOS 

Rord  Dates 

Chief,  Stage  Mgmt  Branch 

0-3 

53A14 

81-88 

Stage  Mgr 

0-3 

53A14 

84-88 

Stage  Mgr 

0-3 

53A14 

84-88 

Data  Mgr 

CWO 

741A 

84-88 

NGOIG,  Detachment  1  Note  1 

E-7 

16H40 

81-88 

QA  Mgr,  Assur  Mgmt  Br 

E-7 

74F40 

84-88 

NCOIC,  Test  Plans  &  Proc  Br 

E-7 

16H40 

82-88 

CM  Mgr,  Assur  Mgmt  Br 

E-7 

74F40 

84-88 

NCOIC,  Central  Admin  Div 

E-6 

71L30 

80-88 

Pseudo  Pilot 

E-6 

16H30 

85-88 

Ch,  Scheduling  and  Test  Mgmt  Br 

E-6 

16H30 

81-88 

Simulator  Operator 

E-6 

16H30 

84-88 

Controller /Operator,  Trng  Br 

E-5 

16H20 

82-88 

Admin  Specialist 

E-5 

71L20 

81-88 

Acc  Test  Mon,  Assur  Mgmt  Branch 

E-5 

74F20 

82-88 

Programmer,  Software  Mgmt  Branch 

E-5 

74F20 

82-88 

Simulator  Operator 

E-5 

25L20 

84-88 

Simulator  Operator 

E-5 

25L20 

84-88 

Simulator  Operator 

E-5 

25L20 

84-88 

Simulator  Operator 

E-5 

25L20 

84-88 

Simulator  Operator 

E-5 

25L20 

84-88 

Scheduler,  Schd  Sc  Test  Mgmt  Br 

E-4 

16H10 

82-88 

Clerk  Typist,  Detachment  1  Note  1 

GS-4 

3 1804 

81-88 

•»»-- .. 


Note  1  Ft  Bliss,  TX 
Note  3  Hurlburt  Fid,  FL 
Note  6  Fullerton,  CA 
Note  7  PT  Loma,  CA 
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Irmy  Equipment  and  Facilities  Requirements 


Range  and  Test  Facility  Support 


Item  Qty 

Location 

Read  Dates  (FY) 

PATRIOT  FU  (PTOS)  1 

Ft  Bliss 

84-87 

PATRIOT  Bn  FDC  (PTOS)  1 

Ft  Bliss 

85-87 

PATRIOT  Bde  FDC  (AN/TSQ-73)  1 

Ft  Bliss 

85-87 

Operations  Personnel  (Test  Facility) 

Personnel  Description  Oty 

Location 

Reqd  Dates  (FY) 

a.  PATRIOT  Battery  Crew 

TCO  (OFF)  14E  2 

Ft  Bliss 

84-87 

TCA  (NCO)  24T30/20  2 

Ft  Bliss 

84-87 

b.  PATRIOT  Bn  FDC  Crew 

TCO  (OFF)  14E  2 

Ft  Bliss 

85-87 

TCA  (NCO)  24T40/30  2 

Ft  Bliss 

85-87 

c.  Brigade  FDC  Crews 

TAC  Dir  (OFF)  14G  2 

Ft  Bliss 

85-87 

Asst  Dir  (NCO)  4 

Ft  Bliss 

85-87 

25L40/30 

d.  CRC  (Missile  Control  Center)  Crew 

SAM  A  (OFF)  14E  or  14G  1 

TBD 

86-87 

SAMA  Tech  (NCO)  16H30  1 

TBD 

86-87 

or  25L30 

MAO  (OFF)  14E  2 

TBD 

86-87 

MAO  Tech  (EM)  16H10  2 

TBD 

86-87 

or  25L10 
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3.  Supplies 

Item 

Qty 

Location 

Reqd  Dates  (FY) 

Office  Supplies 

6  Personnel 

Ft  Bliss 

81-88 

4.  Other  Equipment/Facilities 

Other  equipment/facilities  necessary  includes  office  space  for  six  (6)  JTF  and  five 
(5)  contract  personnel  at  Ft  Bliss,  office  furniture,  typewriters,  telecopier,  projector, 
telephones,  etc.  These  are  too  numerous  to  list  in  this  document  and  can  be  determined  by 
contacting  the  JTF. 


111.  Other 

Additional  personnel  requirements  exist  for  which  the  authorization  source  has  yet 
to  be  determined.  Possible  sources  of  authorization  are  military  or  civil  service  personnel 
from  one  or  both  of  the  Services  or  contract  hire. 


Position 

Grade 

AF5C/MOS 

Rqrd  Dates  (FY) 

Computer  Operators  (8) 

E5 

51150/74D20 

84-88 

Computer  Programmers  (4) 

E5 

5U51/74FZ0 

84-88 
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PMP  ACRONYMS  LISTING 


4ATAF 

Fourth  Allied  Tactical  Air  Force 

ABL 

Allocated  Baseline 

AD 

Data  Automation  Directorate 

AFB 

Air  Force  Base 

AFOTEC 

Air  Force  Operational  Test  and  Evaluation  Center 

ATDL-1 

Army  Tactical  Data  Link-1 

BDE 

Brigade 

BN 

Battalion 

BVR 

Beyond  Visual  Range 

CAT  I 

Category  I  Hardware  Tests 

CDR 

Critical  Design  Review 

Cl 

Configuration  Item 

CIS 

Combat  Identification  System 

CISPO 

Combat  Identification  System  Program  Office 

CM 

Configuration  Management 

COMSEC 

Communications  Security 

COR 

Contracting  Officer  Representative 

CPAF 

Cost  Plus  Award  Fee 

CPC 

Computer  Program  Component 

CPCI 

Computer  Program  Configuration  Item 

CPT 

Computer  Program  Tests 

CRC 

Control  and  Reporting  Center 

CRP 

Control  and  Reporting  Post 

CSF 

Central  Simulation  Facility 

CSS 

Central  Simulation  System 

C2 

Command  and  Control 

C3 

Command,  Control  and  Communications 

C3I 

Command,  Control,  Communications  and  Intelligence 

DCA 

Design  Configuration  Audit 

DDR&E 

Director,  Defense  Research  and  Engineering 

DDT&E 

Director  Defense  Test  and  Evaluation 

DO 

Test  Operations  Directorate 

DoD 

Department  of  Defense 

DPM 

Deputy  Program  Manager 

DSS 

Direct  Subsystem 

DTD 

Deputy  Test  Director 

DTG 

Date  Time  Group 

ECM 

Electronic  Countermeasures 

ECS 

ETS  Communications  Subsystem 

ETS 

Evaluation  Testbed  System 

FBL 

Functional  Baseline 

FCA 

Functional  Configuration  Audit 

FDC 

Fire  Direction  Center 

FSDE 

Final  System  Design  Evaluation 

FT 

FU 

FWG 

FYDP 

GEADGE 

GFE 

GFI 

HCI 

IAW 

IDA 

IDR 

IFF 

IFFN 

IOT&E 

IPO 

ISS 

IT 

IV&V 

JCS 

JFAAD 

JINTACCS 

JTD 

JTDE 

JT&E 

JTF 

LPU 

MC 

MENS 

MIF 

MIL  STD 

MOA 

MOE 

MPC 

MPFF 

MSPU 

NADGE 

NATO 

NE-3A 

NIS 

NISPO 

OAT 

OPR 

OR/SC 

OSD 

OTEA 


Functional  Tests 
Fire  Unit 

Financial  Working  Group 
Five  Year  Development  Plan 

German  Air  Defense  Ground  Environment 
Government  Furnished  Equipment 
Government  Furnished  Information 

Hardware  Configuration  Item 

In  Accordance  With 
Institute  for  Defense  Analyses 
Interim  Design  Review 
Identification  Friend  or  Foe 
Identification  Friend,  Foe,  or  Neutral 
Initial  Operational  Test  and  Evaluation 
Input-Process  Out 
Indirect  Subsystem 
Integration  Tests 

Independent  Verification  and  Validation 

Joint  Chiefs  of  Staff 

Joint  Forward  Area  Air  Defense 

Joint  Interoperability  of  Tactical  Command  and  Control 
Systems 

Joint  Test  Director 

Joint  Test  Director  Executive  Officer 

Joint  Test  and  Evaluation 

Joint  Test  Force 

Live  Participating  Unit 

Model  Committee 
Mission  Element  Needs  Statement 
Manual  Input  Facility 
Military  Standard 
Memorandum  of  Agreement 
Measure  of  Effectiveness 
Message  Processing  Center 
Multi  Purpose  Fighter  Facility 
Manned  Simulated  Participating  Unit 

NATO  Air  Defense  Ground  Environment 
North  Atlantic  Treaty  Organization 
NATO  Airborne  Early  Warning  System 
NATO  Identification  System 
NATO  Identification  System  Program  Office 

Operational  Acceptance  Testing 

Office  of  Primary  Responsibility 

Operational  Requirements/System  Characterization 

Office  of  the  Secretary  of  Defense 

Operational  Test  and  Evaluation  Agency 
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OTP 

Outline  Test  Plan 

OUSDRE 

Office  of  The  Under  Secretary  of  Defense  for  Research 
and  Engineering 

PADIL 

PATRIOT  Air  Defense  Information  Language 

PBL 

Product  Baseline 

PCA 

Product  Configuration  Audit 

PDR 

Preliminary  Design  Review 

PM 

Program  Manager 

PMP 

Program  Master  Plan 

PPS 

Program  Performance  Specifications 

PRR 

Program  Requirements  Review 

PSDE 

Preliminary  System  Design  Evaluation 

PU 

Participating  Unit 

PUSIM 

Participating  Unit  Simulation 

QA 

Quality  Assurance 

RM 

Resource  Management  Directorate 

RTS 

Real  Time  Test  Subsystem 

SAC 

Senior  Advisory  Council 

SAM 

Surface-to-Air  Missile 

SDP 

Support  Data  Processing 

SIS 

Special  Information  System 

SOW 

Statement  of  Work 

SPU 

Simulated  Participating  Unit 

sss 

Satellite  Simulation  Subsystem 

ssu 

Satellite  Simulation  Unit 

ST 

Special  Hardware  Tests 

TAB 

Technical  Advisory  Board 

TAC 

Tactical  Air  Command 

TACS/TADS 

Tactical  Air  Control  Systems/Tactical  Air  Defense  Systems 

TADIL 

Tactical  Digital  Information  Link 

TCM 

Test  Control  Monitor 

TDA 

Deputy  Test  Director,  Army 

TDF 

Deputy  Test  Director,  Air  Force 

TOR 

Testbed  Operational  Requirements 

TPO 

Test  Program  Outline 

TRCO 

Technical  Representative  to  the  Contracting  Officer 

TSP 

Tactical  Simulation  Program 

USAF 

United  States  Air  Force 

USDRE 

Under  Secretary  of  Defense  for  Research  and  Engineering 

USPU 

Unmanned  Simulated  Participating  Unit 

VBD 

Version  Baseline  Delivery 

V<5cV 

Verification  and  Validation 
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MODEL  DEVELOPMENT  PROCESS 


Purpose.  The  purpose  of  this  annex  is  to  describe  the  model  development  process 
for  representing  systems  within  the  Identification  Friend,  Foe,  or  Neutral  (IFFN) 
Evaluation  Testbed  System  (ETS).  The  development  process  described  within  this 
annex  will  apply  to  those  models  that  supplement  the  tactical  hardware/software 
comprising  the  live  participating  unit  (LPU)  and  manned/unmanned  simulated 
participating  units  (MSPU/USPU),  hereafter  known  as  a  participating  unit  (PU). 
The  testbed  will  employ  computer  models  in  cases  where  well  defined  physical 
processes  are  to  be  modeled  or  where  the  fidelity  requirements  for  representing 
the  man-machine  interaction  are  less  severe.  These  models  fall  into  two 
categories:  interactive  and  noninteractive. 

o  Interactive  models  react  dynamically  (in  real-time)  to  perceived 
changes  in  the  air  battle  situation.  They  may  receive  inputs  such  as  data  link 
messages  from  the  other  models  or  LPUs  and  may  initiate  messages  either  on 
their  own  or  in  response  to  stimuli.  The  output  of  these  models  is  not  pre¬ 
determined  and  is  conditional  on  the  specific  dynamics  of  the  air  battle.  The 
applications  for  interactive  models  will  be  as  follows: 

-  Sensor  models:  these  must  react  to  events  such  as  aircraft  kills, 
removal  of  jammers,  and  selection  of  operating  modes. 

-  Missile  models:  real-time  interactive  missile  models  will  be 
employed  to  accomplish  real-time  removal  of  killed  aircraft. 

-  Dynamically  controlled  aircraft  models:  these  will  represent 
those  aircraft  in  the  scenario  whose  flight  trajectories  and  actions  are  reactive 
to  the  air  battle  environment  in  realtime  without  human  interaction. 

o  Noninteractive  models  do  not  react  to  the  air  battle  dynamics.  They 
are  a  less  complex  class  of  models  and  simply  generate  selected  messages  and 
actions  at  preprogrammed  times  according  to  a  script  prepared  prior  to  the  test. 
The  models  are  considered  suitable  for  emulating  those  facilities  that  do  not 
dynamically  interact  with  the  identification  process,  but  that  provide  orders, 
procedures,  and  other  information  on  a  one-way  basis.  This  would  apply  to 
certain  higher  echelon  planning  facilities.  Noninteractive  models  will  also  be  the 
means  of  representing  those  aircraft  following  programmed  flight  profiles  which 
are  not  automatically  reactive  to  the  air  battle  environment  or  under  pseudopilot 
control. 

General  Model  Requirements  and  Philosophy.  Three  general  levels  of  computer 
models  are  required  to  support  test  operations. 

o  Level  1  Models:  These  models  represent  processes  or  functions  that 
directly  influence  the  identification  process  and  interact  directly  with  the 
equipment  and  personnel  of  an  LPU.  They  will  present  realistic  information, 
responses  and  displays  to  LPU  components  and  possess  sufficiently  realistic 
overall  performance  in  areas  that  would  affect  the  identification  process. 


In  sensor  models,  detection  ranges  of  targets  (by  specific  aircraft 


type/configurations)  are  Intended  to  provide  close  (+  10%)  approximations  of 
actual  detection  ranges.  They  are  not  intended  to  be  refined  to  a  level  which 
would  permit  use  to  predict  actual  real-world  system  performance  for  analytical 
purposes  particularity  under  marginal  operating  conditions  such  as  heavy  ECM  or 
clutter  conditions  where  operator  skills  become  critical  to  system  performance. 

-  Display  quality  of  raw  video,  when  modeled,  must  be  such  that 
operators  will  not  be  able  to  discern  the  difference  between  simulated  displays 
and  "live"  displays.  This  must  be  true  in  all  specified  types  of  ECM  as  well  as 
terrain  or  velocity  clutter. 

-  Display  quality  of  processed  video  displays  must  emulate  all 
characteristics  of  the  real  system. 

-  Special  response  characteristics  of  sensor  models  which  affect 
either  the  operator,  the  tracking  system  or  both  must  be  emulated  so  that 
operators  cannot  distinguish  between  the  real  and  simulated  target  responses. 
One  example  is  the  characteristic  response  of  the  Improved  Hawk  High  Power 
Illuminator  Radar  to  helicopter  rotary  wing  blade  modulation. 

-  IFF  responses,  both  sensor  system  and  displays,  must  be  modeled 
equivalent  to  live  operations. 

-  For  models  representing  sensors  organic  to  an  LPU,  the  actual 
point  of  signal  insertion  will  differ  and  be  a  function  of  the  design  and 
construction  of  each  sensor.  Since  less  modeling  is  required  as  more  of  the 
actual  system  is  used,  as  a  general  rule,  signals  should  be  inserted  as  close  to  the 
sensor  antenna  as  possible.  These  models  must  take  into  consideration  any 
processing  loss,  such  as  between  antenna,  receiver  and  signal  insertion  point. 
There  is  no  requirement,  nor  is  it  intended  to  simulate  and  inject  RF  signals  at 
the  antennas  themselves. 

°  Level  2  Models;  These  models  represent  processes  or  functions  that 
provide  inputs  to  the  actual  manned  modes  in  the  context  of  the  scenario  in 
progress.  The  models  must  provide  realistic  information  and  responses  to  the 
LPUs,  however,  the  actual  process  need  not  be  duplicated. 

-  In  sensor  models  detection  ranges  need  only  be  modeled  on  the 
basis  of  nominal  detection  curves  versus  target  cross-section  presented.  The 
nominal  detection  ranges  should  be  reduced  by  a  factor  which  would  allow  for  lag 
between  detection  and  track  establishment.  Low  altitude  effects  should  be 
accounted  for  by  coarse  factors,  and  target  cross-section  effects  also  accounted 
for  on  a  much  coarser  scale  than  Level  1.  Two  points  must  be  remembered  when 
considering  these  models. 

*  All  targets  in  the  area  of  responsibility  which  provide 
"trackable"  signals  based  on  the  above  criteria,  must  produce  tracks. 

*  The  track  generation  of  the  simulation  must  be  generally 
"true  to  life"  so  that  targets  in  areas  of  system  overlap  are  normally  visible  to 
both  tiie  manned  and  unmanned  nodes.  This  factor  obviously  produces  an  effect 
at  a  point  where  simultaneous  track  reports  are  available. 

-  Level  2  models  of  simulated  participating  units  will  provide,  on 
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demand,  the  air  situation  as  seen  by  the  simulated  system  in  a  prescribed 
symbology  format.  They  need  not  be  capable  of  generating  sensor  video 
presentations. 


-  Whenever  special  response  characteristics  show  as  effects  on  data 
link  transmissions,  they  should  be  incorporated  into  the  model. 

-  Modeled  IFF  interrogation  patterns  may  either  be  preprogrammed 
or  directly  controlled  by  a  simulation  controller.  IFF  returns  affect  simulation 
tracks  only  in  a  gross  performance  sense  in  accounting  for  jamming  or  other 
known  undesirable  signal  characteristics.  For  certain  types  of  scenarios,  the  IFF 
effects  on  the  simulated  systems  must  be  capable  of  rapid  reprogramming  by  the 
simulator  controllers  during  a  trial  run  to  maintain  realism. 

o  Level  3  Models:  These  models  represent  processes  or  functions  that 
provide  background  effects,  produce  non-interactive  responses  or  do  not  directly 
interact  with  LPUs.  They  need  only  provide  very  coarse  representations  to  input 
tracks  or  information  to  the  system  for  realism. 

Model  Committee.  A  Model  Committee  was  chartered  to  provide  technical 
support  to  the  Joint  Test  Force  (JTF)  in  those  disciplines  not  readily  available  in 
assigned  personnel.  The  Model  Committee  consists  of  technical  representatives 
from  each  of  the  participating  services.  Institute  for  Defense  Analyses  (IDA), 
Logicon,  JTF  staff,  and  other  industry  and  government  experts  as  deemed 
necessary  to  evaluate  candidate  PU  System  models.  The  Model  Committee  is 
strictly  a  supporting  forum  that  will  review  and  assess  models  proposed  by 
Logicon  and  make  recommendations  and  advisements  to  the  Joint  Test  Director 
(JTD)  through  the  JTF  staff.  Logicon  will,  in  turn,  receive  direction  from  the 
JTD  to  alter  models  appropriately.  The  Model  Committee  will  be  exercised 
through  the  organization  shown  at  TAB  A.  The  Model  Committee,  at  the 
working  level,  will  be  allowed  to  organize  as  they  see  fit  to  best  utilize  the 
expertise  available  to  accomplish  goais/objectives.  Block  coordinators  will  be 
assigned  from  the  JTF  to  guide  the  actions  of  the  various  subgroups.  They  will 
also  be  responsible  for  collating  and  providing  to  the  Model  Committee  Chairman 
inputs  for  minutes  and  aid  in  preparing  recommendation  to  JTD.  The  Model 
Committee  Chairman  will  be  from  the  Test  Operations  Directorate  (DO)  and 
selected  by  the  Director.  The  Data  Automation  Directorate  (AD)  will  provide 
technical  assistance/advisement  to  DO  on  modeling.  The  Chairman  will  be 
responsible  for  determining  when  meetings  will  be  held,  inviting  members, 
preparing  an  agenda,  chairing  the  meetings,  providing  appropriate  materials/doc¬ 
uments,  preparing  recommendation  to  JTD,  preparing/distributing  minutes, 
providing  feedback  to  members,  and  overall  coordination  with  Logicon  on  model 
effort.  The  Deputy  Test  Directors  (DTDs),  Steering  Group,  and  IDA  Project 
Leader  will  act  in  an  advisory  capacity  to  the  JTD.  Detailed  responsibilities  for 
the  modeling  process  will  be  discussed  later. 

Model  Development  Process.  The  modeling  process,  as  illustrated  in  TAB  B,  is  a 
dynamic,  iterative  process.  This  process  will  apply  to  each  phase  of  program 
development.  Once  the  testbed  system  requirements,  as  stated  in  the  Type-A 
Specification  and  Testbed  Operational  Requirements  (TOR)  are  analyzed  to 
establish  the  scope  and  level  of  modeling  detail,  the  submodels  for  each  IFFN 
ETS  PU  will  be  developed  in  accordance  with  a  design,  implementation,  and 
testing  process  for  which  major  activities  will  occur  and  products  be  developed. 
The  following  steps  will  constitute  the  development  process: 


verify  systems  and  environment  to  be  represented.  Before  a  PU  can  be 
represented  by  a  set  of  submodels,  the  JTF  will  acquire  an  understanding  of  the 
performance  and  operational  characteristics  of  the  system  to  be  modeled.  The 
depth  of  this  understanding  is  guided  by  A-Spec  requirements,  MOEs,  test 
objectives,  service  requirements,  technical  and  operational  procedures,  data  to 
be  collected,  and  is  a  product  of  analyzing  the  following  real-system 
definition/performance  documents: 

-  PU  System  Specification 

-  Functional  Requirements  Specification 

-  Detailed  Design  Specification 

-  Interface  Design  Specification 

-  System  Description  Manuals 

-  Operational  Manuals 

-  System  User  Manuals 

-  Training  Manuals 

In  addition  to  these  document  analyses,  the  OR/SC  is  also  based  on  data  gathered 
from  direct  observation  and/or  demonstration  of  the  actual  system,  as  well  as 
information  provided  by  operators  of  the  actual  system.  The  JTF  will  then 
prepare  an  OR/SC  package  for  presentation  to  Logicon  to  include: 

-  Operational  Overview 

-  Functional  and  Data  Flow  Diagrams 

-  Detailed  Technical  Outline 

-  Interface  Diagrams 

-  Performance  Factors 

-  Operational  Factors 

-  Model  Inputs/Outputs 

-  Effects  to  be  Included 

-  Interactions  with  other  Testbed  Elements 

The  format  for  this  package  will  be  in  the  form  of  an  operational  requirements 
annex  to  the  TOR.  In  parallel  with  JTF  efforts,  Logicon  will  be  performing 
essentially  the  same  tasks  developing  their  own  system  characterization  (Ref: 
Model  Requirements  Document).  The  JTF  package  will  provide  our  philosophy, 
conceptual  guidance,  and  operational  requirements  to  Logicon.  Between  the  two 
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efforts,  an  interactive  process  will  evolve  to  provide  a  check  and  balance  on  the 
two  efforts  to  ensure  PU  systems  are  accurately  portrayed,  define  required 
model  fidelity,  and  detailed  performance/operationai  features.  The  OR/SC 
development  step  will  be  the  product  of  the  Program  Requirements  Review 
(PRR).  The  PRR  is  conducted  30  days  prior  to  the  beginning  of  each  stage  to 
ensure  that  program  requirements  specific  to  the  particular  PU  being  integrated 
during  that  stage  of  development  will  support  test  objectives,  test  design,  and 
test  plans.  The  operational  requirements  package  will  be  used  to  update  the  A- 
Spec.  While  trying  not  to  fall  into  a  "design  to"  process,  the  JTF  will  reserve  the 
right  to,  on  a  case-by-case  basis  to  be  able  to  exert  a  positive  influence  on  model 
design  and  eliminate  contractor  misinterpretation  of  requirements.  Once  agreed 
upon,  Logicon  will  commence  model  construction.  The  relationship  of  this 
procedure  to  the  program's  overall  documentation  scheme  is  shown  at  TABS  B 
and  C. 

o  Model  Construction/Deveiopment.  Model  construction/development 
will  take  place  in  four  steps: 

-  Baseline  Model  Definition 

-  Preliminary  Model  Specification 

-  Final  Model  Specification 

-  Model  Product  Baseline 

A  review  of  each  step  of  development  will  be  done  by  the  JTF  and  the  Model 
Committee  (through  document  review  or  formal  Model  Committee  meeting), 
with  recommendations  made  to  JTD  as  to  suitability  of  models.  The  four  steps 
as  to  contents,  deliverables,  and  responsibilities  are: 

o  Baseline  Model  Definition.  The  Baseline  Model  Definition  provides  an 
overview  of  PU  system  features  to  be  modeled,  and  provides  an  initial  statement 
of  what  functions  and  techniques  are  necessary  to  simulate  those  features.  The 
system  characterization  data  is  the  starting  point  for  the  baseline  model 
definition  development.  Deliverable  documents  of  PU  consideration  will  include 
(not  contract  deliverables,  but  delivered  by  Logicon  in  support  of  JTF/Model 
Committee  review  activities): 

-  Operational  Overview 

-  System  Characterization 

-  Baseline  Model  Definition 

These  documents  will  provide  the  following  engineering  data: 

-  Identification  and  definition  of  performance  factors 

-  Identification  and  definition  of  key  functions 

-  Identification  and  definition  of  modeling  techniques 

-  High  level  Input-Process-Out  (IPO)  diagram  for  each  submodel 
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Document  delivery  (30  days  after  start  of  stage)  will  be  included  in  the  Program 
Plan  and  Schedules  document.  Selected  Model  Committee  members  (determined 
by  block  coordinators)  will  receive  copies  of  documents  and  be  asked  to 
review/assess  and  provide  comments  to  JTF.  No  formal  Model  Committee 
meeting  will  be  convened  for  this  step.  Detachment  8  will  be  responsible  for 
forwarding  documents  to  Model  Committee  members.  An  OPR  from  DO  will 
collate  JTF  and  Model  Committee  comments  and  provide  a  recommendation  to 
the  JTD  as  to  the  suitability  of  system  model  at  this  point.  The  JTD,  through 
the  TRCO,  will  provide  feedback  to  Logicon  and  the  Model  Committee  Chairman 
to  the  Model  Committee.  Logicon  will  use  that  feedback  in  developing  the  next 
step  in  the  process. 

o  Preliminary  Model  Specification.  The  Preliminary  Model 
Specification  describes  in  detail  all  the  operational  and  functional  requirements 
necessary  to  design  and  test  the  submodels  representing  the  PU  Systems.  It  will 
include  the  IPO  specifications  and  model  interface  diagrams  for  each  submodel, 
plus,  define  model  data  bases  to  include  performance  tables  for  table-driven 
models.  Document  delivery  will  be  included  in  the  Program  Plan  and  Schedules 
Document  as  a  part  of  PDR  deliverables.  Det  8  will  be  responsible  for 
forwarding  document  to  Model  Committee  members.  Model  Committee 
chairman  will  provide  Detachment  8  with  a  cover  letter  and  a  mailing  list. 
There  will  be  a  formal  Model  Committee  meeting  in  conjunction  with  PDR,  and 
will  coincide  with  PDR  review  dates  so  that  Model  Committee  comments  can  be 
integrated  into  PDR  comments.  Model  Committee  Chairman  will  be  responsible 
for  determining  when  Model  Committee  will  meet  and  for  preparing  an 
agenda/goals  for  the  meeting.  Model  Committee  Chairman  will  chair  meeting 
and  ensure  Model  Committee  members  adhere  to  schedule  with  the  aim  of 
satisfying  goals.  At  the  termination  of  Model  Committee  meeting,  Service 
coordinators  (MC  Chairman)  will  collate  Model  Committee  comments  and 
recommendations  and  prepare  a  coordinated  staff  assessment  to  the  3TD.  The 
JTD  will  use  this  in  determining  his  position  on  Logicon's  modeling  effort. 
Feedback  to  Logicon  will  be  through  the  PDR  process/format/schedule  for 
providing  JTF  review  of  documentation.  Feedback  to  the  Model  Committee  will 
be  in  the  form  of  newsletter.  Model  Committee  Chairman  will  be  responsible  for 
preparing  and  forwarding  newsletter.  Logicon  will  use  feedback  in  developing 
the  next  step  in  the  process. 

o  Final  Model  Specification.  The  Final  Model  Specification  will  be  an 
updated  and  completed  version  of  the  Preliminary  Model  Specification. 
Document  delivery  will  be  in  conjunction  with  CDR  and  IAW  Program  Plan  and 
Schedules  Document.  The  Final  Model  Specification  will  be  issued  as  a  part  of 
the  PUSIM  Program  Performance  Specifications  (PPS).  Logicon  will  identify 
sections  pertinent  to  modeling;  Detachment  8  will  forward  documents  to  Model 
Committee  members  for  review  and  comment.  There  will  be  a  formal  Model 
Committee  meeting  scheduled  in  conjunction  with  CDR  and  will  coincide  with 
CDR  schedule.  Responsibilities  will  be  as  in  the  aforementioned  discussion. 
Logicon  will  use  feedback  in  developing  the  next  model  development. 

o  Model  Product  Baseline.  The  Model  Product  Baseline  reflects  the 
detailed  design,  codirtg7and  testing  based  on  the  Final  Model  Specification  in  the 
corresponding  PUSIM  PPS.  Each  PPS  will  generate  a  series  of  design  and  test 
documents.  In  addition,  there  will  be  common  interface  and  data  base 
documents.  The  resulting  list  of  documents,  defining  the  Model  Product  Baseline, 
include  the  following: 
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-  Program  Design  Specification 

-  Program  Design  Descriptions 

-  Interface  Design  Specifications 

-  Data  Base  Documents 

-  Test  Plans 

-  Test  Specifications 

-  Test  Procedures 

-  Test  Reports 

-  Program  Packages 

Model  Product  Baseline  documents  will  be  included  in  the  Version  Baseline 
Delivery  and  IAW  Program  Plan  and  Schedules  Document.  Logicon  will  identify 
pertinent  model  documents  and  Detachment  8  will  forward  to  Model  Committee 
members  for  review.  As  this  is  the  final  software  delivery,  no  formal  Model 
Committee  meeting  will  be  held.  Selected  Model  Committee  members  will  be 
asked  to  review  models  during  operational  acceptance  testing. 

o  Certification.  Certification  is  an  administrative  procedure 
performed  to  ensure  enough  evidence  is  available  (model  accurately  portrays  PU 
in  enough  fidelity  to  satisfy  testing  requirements/objectives)  to  state,  with  near 
certainty,  that  the  system  will  satisfy  the  user's  need.  Certification  will  be  an 
ongoing  process  commencing  with  the  four-step  review  process  by  the  JTF  and 
Model  Committee  and  concluding  with  Service  acceptance  of  models.  In  order  to 
ensure  that  an  adequate  Service  certification  process  is  accomplished  on  the 
models,  the  proper  representation  from  within  the  Services  will  be  identified  and 
sit  on  the  Model  Committee.  The  IFFN  Deputy  Test  Directors  (IAW  Model 
Charter)  will  coordinate  with  each  Service  on  a  single  agency  to  review  and  pass 
judgment  on  final  model  versions  of  models.  Final  certification  of  models  will  be 
a  subset  of  overall  testbed  certification. 

o  Operational  Acceptance  Testing  (OAT).  OAT  is  a  demonstration 
under  operational  conditions  to  show  that  the  testbed  performs  in  accordance 
with  the  Government's  specifications  and  satisfies  all  Government  requirements. 
Although  successful  OAT  may  not  meet  certification  criteria,  it  will  be  observed 
and  reviewed  by  the  3TF,  Services,  and  Model  Committee  as  a  part  of  model 
certification.  The  following  steps  will  establish  certification  review  process 
during  OATs 


-  Establish  criteria 

•  Collect  reference  data  from  field  exercises,  etc 

-  Observe/record  test  data 

-  Analyze  test  data  against  reference  data 
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-  Refine  models  as  required 

-  Implement  changes 

-  Accept  model  for  testbed  operations 

-  Implement  model  in  testbed 

o  Verification  and  Validation.  Throughout  the  model  development 
process,  SAI  will  conduct  an  independent,  in-depth  model  requirements  analysis 
through  review  of  all  model  documents.  SAI  will  perform  the  review  and 
evaluation  in  a  quantitative  manner  to  determine  the  suitability  and  approach  to 
modeling  regarding: 

-  Traceability  between  models  and  requirements  from  higher-level 
documentation. 

-  Completeness  and  compatibility  with  other  models  and 
requirements. 


ETS. 


Degree  of  fidelity  necessary  to  meet  requirements. 

Model  performance  and  computational  demands  placed  on  the 


-  Sufficient  detail  and  adequacy  of  model  descriptions. 

SAI  will  provide  a  report  to  the  JTF  summarizing  their  review,  giving  anomalies 
discovered  during  the  review  and  comments  regarding  implementation  risks. 
This  V&V  process,  as  well  as  the  Model  Committee  actions,  will  provide  another 
measure  of  checks  and  balances  to  ensure  model  correctness  and  credibility. 

o  Schedule.  A  schedule  is  shown  at  TAB  C.  Dates  will  be  determined 
based  on  Program  Plan  and  Schedules  Document.  Dates  will  be  entered  into 
Project  Management  System  for  tracking/update. 

o  Responsibilities.  Some  responsibilities  are  laid  out  in  earlier 
discussion.  Pertinent  personnel/agency  responsibilities  are  delineated: 

-  DO.  Primarily  responsible  for  determining  PU  system 
characteristics  and  operational  requirements.  DO  will  support  Logicon  in  their 
efforts  to  define  same.  Refine  model  requirements  through  the  TRCO  process, 
then  review  for  operational  considerations.  Interface  with  Model  Committee 
members  and  Service  agencies  to  resolve  issues  and  recommendations.  Interface 
with  rest  of  staff  on  schedule.  Chair  Model  Committee.  Provide  inputs  into 
certification/OAT. 

-  AD.  Primarily  responsible  for  analyzing  the  acquisition  schedule 
to  determine  what  products  (GFI,  documents,  operational  requirements,  system 
characteristics,  etc.)  are  required  to  support  model  milestones  (PDR,  CDR,  etc.); 
these  to  come  from  3TF  staff  or  from  outside  agencies.  Responsible  for  review 
of  model  technical  specifications.  Will  establish  TRCO  process  for  providing 
feedback  to  Logicon.  Interface  with  Model  Committee  members  on  issues  and 
concerns  (meetings,  telephone,  message,  etc.).  Provide  inputs  to 
certification/OAT. 
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-  RM.  RM  will  Incorporate  AD/DO  inputs  into  a  schedule  and  enter 
it  into  the  Project  Management  System,  and  then  track  and  update  schedule,  as 
required.  They  will  also  handle  funding  requests  for  Model  Committee  members. 
Contracting  expertise  may  be  required  if  outside  agencies  such  as  EC  AC,  JTCG, 
etc.  are  used. 


-  Model  Committee  Chairman.  Chairman  will  be  responsible  for  all 
Model  Committee  activities.  Duties  will  be  to:  determine  block  coordinators 
for  each  phase,  track  schedule,  schedule,  prepare  agendas,  and  chair  Model 
Committee  meetings,  coordinate  with  Logicon  on  meetings,  deliverables, 
feedback,  (etc.),  write  minutes  and  Model  Committee  newsletter,  track 
membership,  write/update  charter,  coordinate  JTF  model  activities,  and  appoint 
OPRs  for  each  phase. 

-  DTDs.  Will  request  Service  inputs/coordination,  coordinate 
Service  acceptance/certification/validation,  advise  3TD,  and  obtain  Service 
personnel  for  OAT. 

-  JTD.  Will  approve  model  specifications  and  provide  funding 

approval. 

-  3TDE.  Will  provide  administrative  assistance  to  Model 
Committee  chairmen  and  staff,  as  required. 

-  Detachment  1.  Aid  in  defining  operational  requirements/system 
characteristics,  provide  inputs  to  certification/OAT,  and  provide  personnel  for 
model  review. 


-  Detachment  8.  Will  monitor  Logicon's  efforts,  provide  liaison 
between  Logicon  and  JTF  staff,  and  mail  model  documents  to  Model  Committee 
members. 


-  Model  Committee.  Review,  assess,  and  provide  recommendations 
to  JTD  on  model  development/specifications.  Review  models  during  OAT. 

-  Logicon.  Develop  technical  specifications  for  models  and  present 
to  JTF  through  appropriate  documentation.  Brief  same  during  Model  Committee 
meetings.  Interface  with  JTF  and  appropriate  Service  agencies  during  model 
development.  Provide  early  documentation  to  Model  Committee  members  for 
review  prior  to  meetings  through  Detachment  3.  Provide  technical  memos  to  the 
JTF  and  MC  members  after  each  MC  meeting  to  reflect 
recommendations/changes/refinements  to  the  models  and/or  modeling  approach. 
Coding,  testing,  implementation,  and  refinement  of  modeis. 

-  Tech  Support  Contractor.  SYSCON  will  be  used  in  helping 
develop/determine  operational  requirements/system  characteristics.  Aid  in 
model  review  and  assessment.  Analyze  operational  requirements  against 
Logicon's  model  design. 

-  Verification  &  Validation  Contractor.  SAI  will  review  model 
development  documentation  through  each  step. 

-  Services.  Help  determine  operational  requirements/system 
characteristics.  Certify/accept  final  model  products.  Provide  personnel  for 
OAT. 
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-  IDA.  Provide  member(s)  to  Model  Committee.  Interpret  test 
design.  Aid  in  development  of  operational  requirements/systems 
characterization. 

-  Steering  Group.  Advise  JTD  on  model  fidelity  requirements, 
model  development  process,  and  certification.  Other  technical  aspects  of 
modeling/simulation  development,  as  appropriate. 

-  Army/Air  Force  Coordinators.  Provide  interface  between  the 
JTF  and  advisors.  Provide  guidance  and  maintain  direction  of  efforts  toward 
accomplishing  goals.  Organize  to  efficiently  and,  in  a  timely  manner, 
accomplish  goals.  Coordinate  with  other  Service  Coordinators.  Report  upwards 
to  Model  Committee  Chairman.  Aid  in  preparation  of  minutes. 

-  Summary.  For  the  ETS  to  be  credible,  it  must  represent  each 
element  in  a  realistic  manner.  The  model  development  process  is  the  most 
important  undertaking  of  the  JTF  staff  to  ensure  the  testbed  is  realistic  and 
provides  data  to  meet  test  objectives.  It  is  a  dynamic,  iterative  process  that 
provides  a  logical,  structured  road  map  that  integrates  JTF  objectives,  Logicon 
design  efforts,  MIL-STD-1679  contract  deliverables  and  milestones,  and  review 
by  outside  agencies/Services  that  will  produce  achievable  outputs  consistent  with 
testbed  requirements. 
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L  COMMITTEE  ORGANIZATION 


MODEL  DEVELOPMENT  PROCESS 


TAB  B  TO  APPENDIX  H 
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TAB  C  TO  APPENDIX  H 


MODEL  COMMITTEE  SCHEDULE 


Activity 


Time 


Program  Requirements  Review 
Stage  Start 

Baseline  Model  Definition  (BDM)  Delivery 
(Mailed  to  MC) 

Comments  from  MC 

JTF  Review  Complete 
(JTF  endorsement  of  BMD) 

Preliminary  Model  Specification  (PMS)  Delivery  (PDR) 
(Mailed  to  MC) 

PDR 

MC  Meeting 

PDR  Review  Complete  *  , 

(JTF  endorsement  of  PMS) 

Final  Model  Specification  (FMS)  Delivery  (CDR) 
(Mailed  to  MC) 

CDR 


MC  Meeting 


CDR  Review  Complete 
(JTF  endorsement  of  FMS) 


Model  Product  Baseline  (MPB)  Oelivery 
(Mailed  to  MC) 

Version  Baseline  Delivery 
Operational  Acceptance  Testing 
(Models  reviewed  by  MC) 

JTF  Endorsement  of  MPB 


30 

0 

30 

45 

60 

75 

90 

100 

120 

165 


180 

190 


13 

Months 


45 

Days 


Follow-on  stage  activities  will  always  overlap  with  ongoing  stage. 


